校招宝 · 中国校园招聘岗位数据

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is low. The description adds real value by disclosing what the response actually contains — counts, cities, type/industry, structured facts, hot jobs — which sets caller expectations. It stops short of noting limits, pagination on the hot-jobs list, or behavior for an unknown company.

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?

Front-loaded with the verb and resource, then the payload, then the usage trigger — a logical order with no filler. The field enumeration is dense but each item earns its place since there is no output schema. Slightly long for a single-parameter read.

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?

With no output schema, the description usefully compensates by enumerating the returned fields, and the single required parameter is fully documented. It is close to complete; only the shape/size of the nested 热门招聘岗位 list and error handling for a bad slug are left unspecified.

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?

Only one parameter, and schema_description_coverage is 100%: the schema already explains that slug accepts a slug such as 'tencent' or a Chinese name such as '腾讯'. The description's '按企业名或 slug' merely restates this, adding no new syntax or format detail. Baseline 3 applies.

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+resource (获取企业档案) and enumerates the exact payload: 在招岗位数、覆盖城市、企业类型与行业、简介、结构化事实、热门招聘岗位. That company-level scope cleanly separates it from job-level siblings like get_job_detail or search_campus_jobs without needing to open either schema.

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?

Gives concrete trigger phrases — 「这家公司怎么样」「XX 在招什么」 — so the agent knows when to reach for this rather than get_job_detail. It does not, however, name an alternative tool or state any exclusion/negative case.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: results are statistics-level only, contain no questions/answers, and include on-site links that the agent is expected to surface. It does not discuss empty/no-data behavior, which is the only real gap.

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 output payload is front-loaded in the first clause, followed by trigger examples and then the critical scope caveat. The example list is somewhat long but each phrase is a distinct routing hook, so only minor trimming is possible.

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 unnecessary, and annotations cover the safety profile. The description supplies the scope boundary (statistics only, no questions) that the structured fields cannot express; only the behavior when no data matches the unit/section is left unstated.

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 coverage is 100%, so the schema already documents unit, detail, and section (including defaults and the either/or rule). The description only loosely mirrors this with '某家企业或某个考试板块' and adds no syntax, alias, or fallback detail beyond the schema, so the baseline 3 applies.

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 (笔试考情) and then enumerates exactly what is returned: total question count, question-type ranking, past paper list with year/role, and real-vs-mock composition. This is clearly distinct from the siblings (get_company_profile, get_job_detail, get_stats), so an agent can route without opening the schema.

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?

Gives concrete trigger phrasings (「XX 笔试考什么」「XX 有没有历年真题」etc.) that map user intent to this tool, and explicitly states the out-of-scope case: it does not provide actual questions or answers, and the user should be directed to the returned on-site links. Both the when-to-use and the when-not-to-use are present.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the payload includes full JD text (完整信息与 JD 全文), but with no output schema it remains vague about what '完整信息' actually contains and does not mention failure behavior for an invalid ID.

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?

Three short sentences: what it returns, when to use it, and where the key comes from. The purpose and the constraint are front-loaded with no filler.

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 one-parameter read tool with safety annotations and no output schema, the description covers retrieval scope, key sourcing, and the JD payload adequately. Only a brief note on what the returned 'complete info' includes would make it fully self-sufficient.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents the id field and its provenance. The description only repeats that the ID comes from search_campus_jobs, adding no format or validity detail beyond the structured field.

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 (获取) plus resource (单条校招岗位的完整信息与 JD 全文) and scope (单条, keyed by 岗位 ID). It also names the sibling that produces the ID (search_campus_jobs), so an agent can distinguish it from the search tool without inspecting schemas.

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 gives concrete usage contexts: judging match quality, comparing two positions, answering a position's specific requirements, and where the ID comes from. There is no explicit 'when not to use' or statement that bulk retrieval should go through search_campus_jobs, so it stops short of a full routing rule.

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

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

Annotations already declare readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds real behavioral value by enumerating the six specific data-volume figures surfaced and framing the tool's role as explaining 数据边界, which annotations cannot convey.

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 sentences with zero waste: the first front-loads purpose and the returned metrics, the second gives usage triggers. Nothing repeats the name or title gratuitously.

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 zero-parameter stats tool with no output schema, the description supplies both the content (six metrics) and the invocation context (data-completeness questions), which is sufficient for an agent to call and explain it 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 tool takes zero parameters and the schema is empty, so there is nothing to document; baseline is 4. No parameter meaning is needed or missing.

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 (获取) plus resource (数据体量概览) and then enumerates the exact metrics returned: 在招岗位数, 招聘企业数, 覆盖地区数, 求职攻略数, 题库量, 薪资记录数. This clearly distinguishes it from the sibling detail/search tools (get_job_detail, search_campus_jobs).

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?

Gives explicit usage triggers: when the user asks 「有多少校招岗位」, 「数据全不全」, or when the agent needs to explain data boundaries. Clear context for invocation, though it does not name sibling 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.

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

注解已声明 readOnlyHint=true 和 openWorldHint=false，表明这是安全的只读操作。描述额外补充了关键行为上下文：days_left 由服务端按北京时间计算，并明确指示直接采用，不要自行推算。这超出了注解和 schema 所提供的信息，但未涵盖返回格式或分页细节。

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，但描述不需要解释返回值。整体信息足够让 agent 正确调用。

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 描述覆盖率为 100%，因此 schema 已完整记录了 city、days、size 三个参数。描述未对参数语义做额外说明，但基于高覆盖率，基线分 3 分是合适的。

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?

明确说明动词和资源（列出即将截止的校招岗位），并说明了排序方式（按截止日期升序）。虽然未直接点名同级工具，但通过具体描述截止日期场景，与 search_campus_jobs 等区分开来。

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?

明确给出了使用场景：当用户问「有什么快截止的」「哪些岗位马上不能投了」时使用。这完全覆盖了何时使用该工具的指导，无需进一步推断。

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds what the annotations cannot: that the call returns a job list where each entry carries a 校招宝 in-site detail page link, which is genuinely useful pre-call context given there is no output schema. No auth, rate-limit or pagination behavior is disclosed.

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?

Three sentences with no waste: purpose + filter surface first, then usage triggers, then return shape. Each sentence carries distinct information and nothing is repeated from the schema.

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 12-param, no-required-param search tool with full schema coverage, annotations, and no output schema, the description covers purpose, invocation triggers, and the return contract. The only gap is disambiguation from the deadline-oriented sibling list_urgent_deadlines and any note on result pagination.

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 100% — all 12 parameters, including the sort enum and the multi-value/normalization behavior of city, are already documented in the schema. The description's filter list (城市、批次、学历、届别、关键词、行业、企业类型) merely recaps a subset of those same fields, so the baseline 3 applies.

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 names a specific verb+resource (检索中国校园招聘在招岗位) and immediately bounds the scope with the batch taxonomy (秋招/春招/实习/提前批) and the filterable dimensions. An agent can tell this is the broad discovery/list tool versus the ID-based siblings like get_job_detail and get_company_profile.

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 gives concrete trigger utterances — 「有哪些校招岗位」「某城市/某方向/某公司在招什么」「本科能投哪些」 — which is strong contextual guidance. It does not, however, state when NOT to use it or name list_urgent_deadlines as the alternative for deadline-driven questions, even though the overlapping days_left_max parameter creates real ambiguity.

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