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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. However, the description does not disclose the critical mutation semantics: whether 'tags' and 'note' (both required) replace or merge existing values, whether omitted 'status' resets to the default 'candidate', or what the call returns. For an overwrite-style annotation tool this gap is significant.

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?

A single compact sentence with the resource and the affected fields front-loaded and no filler. Brevity is not wasteful, though it tips toward under-specification rather than crispness.

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 a mutation tool with no output schema, 0% parameter description coverage, and no annotation detail beyond generic hints. The description supplies the status enum but omits replace-vs-merge behavior, job identifier semantics, and any result expectation, leaving an agent insufficiently equipped to call it safely.

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% across 4 parameters, so the description carries real weight. It usefully enumerates the allowed status values (candidate/priority/excluded/archived), which the schema does not (no enum, only a default of 'candidate'). It says nothing about 'job_biz_id' or the expected shape/format of the tags array and note string, so compensation is only partial.

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 ('修改' / modify) and resource ('本机岗位' local job annotations) with the concrete field set (tags, note, status). An agent can tell this is an annotation/status-writing tool rather than a search or save tool, though it does not name a sibling such as yupao_save_job to delineate the boundary.

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?

No guidance on when this tool should be used instead of yupao_save_job, yupao_remove_saved_job, or the preset tools, and no prerequisites (e.g. whether the job must first be found via yupao_search_jobs or yupao_get_job_detail). Usage is only inferable from the field list.

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?

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds operational context beyond them: this tool makes no request to 鱼泡, which means no authentication, no rate-limit exposure, and no remote side effects. It does not say whether the capability list is static or reflects runtime state, which is a minor remaining 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?

It is one compact sentence in two clauses, front-loading the three capability states and then the key constraint. Nothing is wasted, and nothing important is buried.

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 zero parameters, full annotation coverage, and no output schema, the definition is nearly complete: it says what is enumerated and that no remote call occurs. The one thing an agent cannot infer is the shape of the returned data, such as whether capabilities come back as names with status flags; the description does not close that gap, but the gap is small for an introspection tool.

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, so the baseline is 4 and there is no parameter semantics to document. The description correctly spends no words on inputs, which is appropriate.

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 gives a specific verb ('查看') and a specific resource (capabilities), broken down into three concrete states: implemented, verified, and not-yet-enabled. It clearly does not overlap with the action-oriented sibling tools, so an agent can distinguish it. It falls just short of 5 because it never states whose capabilities these are, namely the MCP server's own feature set, although the clause '不请求鱼泡' strongly implies that they are local.

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?

'不请求鱼泡' tells the agent that this tool is a cheap local call with no network round trip, which implicitly makes it safe to call before other operations. However, the description never says when to prefer this tool over simply attempting a sibling action, and it names no alternatives or prerequisites. The usage is therefore implied but not stated.

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 declare readOnlyHint=true and openWorldHint=true, but the description adds real behavioral guarantees beyond them: it does not return credentials, does not read chats, and does not send messages. These negative guarantees are exactly the context an agent needs to trust a call with openWorldHint=true, though return behavior is not described.

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?

A single dense sentence with two clauses, front-loading the purpose and immediately following with the safety scope. No filler, nothing repeated.

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 and no parameters, the description carries the full disclosure burden, yet it never says what the check returns (e.g., a boolean availability flag, an error, a status field). The negative disclosures are strong, but the positive result shape is missing for a diagnostic tool whose value is entirely in its answer.

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, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter text 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?

States a specific verb+resource: check whether Yupao can supply IM login material, with an explicit scope limit (no credentials returned). It does not name or differentiate from the sibling yupao_check_session, leaving the agent to infer the distinction, so it stops short of 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?

The phrasing '核对...能否提供 IM 登录资料' implies a preflight check before messaging, and '未登录 SDK' hints at a prerequisite state. However, there is no explicit when-to-use/when-not statement and no named alternative such as yupao_check_session or yupao_prepare_message, so the guidance is only implied.

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 mark the tool read-only, non-destructive, and open-world; the description adds useful behavioral constraints by stating it does not read browser credentials and does not return tokens. It still does not describe the return status or error behavior, but the privacy and scope disclosures are valuable.

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 a single compact sentence with the core action front-loaded and two relevant exclusions following. Every clause earns its place, with no filler or repetition.

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 zero parameters and no output schema, the description carries the full burden of explaining selection and behavior. It explains scope and exclusions, but it does not say what a successful check returns (for example, status, account identity, or expiration), leaving operational ambiguity.

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 no input parameters, so there is nothing for the description to clarify at the parameter level. With zero parameters and 100% schema coverage, baseline 4 is appropriate.

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 (检查) and resource (本机鱼泡登录文件) and narrows scope to explicitly configured files while excluding browser credentials. It is clear, but it does not explicitly distinguish itself from session-related siblings such as yupao_check_messaging_session.

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 implies usage for verifying a locally configured Yupao login file and explicitly rules out browser-credential lookup. However, it gives no explicit when/when-not guidance or named alternative, so the agent must infer selection from context.

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 say readOnly=false, openWorld=true, destructive=false; the description adds real value on top with its human-in-the-loop requirement, the absence of an auto-approve flag, the default-off stance, and the idempotency warning against resending on ambiguous results. It does not say what a given action actually does or whether it can be irreversible despite destructiveHint=false, which is a notable remaining 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?

Four short clauses, front-loaded with the core instruction and each carrying behavioural content — no filler. '默认关闭' is slightly telegraphic (default off for what — the tool, or an auto-approve switch?), which keeps it from a 5.

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 mutating tool with no output schema and zero schema coverage, the safety story is well covered, but two things an agent needs are missing: how to resolve action_id, and what a success vs. failure response means. Adequate but with clear gaps.

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 single parameter action_id has 0% schema description coverage, so the description must compensate, and it does not — nothing explains what an action id is or where to obtain it (presumably from yupao_get_action or a yupao_prepare_* call). '已预览的' hints at provenance but gives no format or sourcing guidance.

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 concrete verb (执行/execute) and a bounded resource (a single, already-previewed action), making clear this is the confirmation step rather than preparation. It does not name a sibling, so it falls short of a 5, but the phrase '已预览' implicitly separates it from the yupao_prepare_* and yupao_get_action 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?

It sets clear conditions: the action must already have been previewed, and a real human must confirm it — no auto-approval parameter exists. It also gives explicit retry guidance ('结果不明不重发' — don't resend when the outcome is unclear). It stops short of naming alternatives such as yupao_get_action for fetching the action id.

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 establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond them: it enumerates what is returned (preview, confirmation summary, execution status, receipt) and restates the non-sending guarantee, which matters for a tool sitting next to an execute sibling.

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?

One sentence, front-loaded with the resource and the returned artifacts, closing with the key constraint. Nothing is redundant.

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 names the return contents and the non-mutating behavior. It falls short only on the provenance of action_id and error behavior for invalid ids.

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 single parameter action_id has 0% schema description coverage, so the description must carry the burden. '具体操作' only loosely implies that action_id identifies an action; it says nothing about where the id comes from (presumably the prepare_* tools) or what happens with an unknown id.

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 pairs a specific verb with its resource: '读取具体操作' (read a specific action) plus the enumerated artifacts it returns (preview, confirmation summary, status, receipt). The closing clause '不执行任何发送' implicitly separates it from yupao_execute_action, though it never names that sibling.

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 only implied: an agent can infer this is the read-side counterpart to yupao_execute_action, but there is no explicit when-to-use statement, no mention of calling it before executing, and no named alternative.

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=true, so the safety profile is covered. The description adds that the return is a full JD intended for analysis, but says nothing about failure behavior when the ID is invalid or stale, or about payload size.

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?

A single front-loaded sentence with no filler. The precondition and the purpose are both packed into one clause without repetition of the tool name.

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-only fetch with no output schema, the description covers what is fetched (full JD) and why it exists (job analysis). Only edge-case behavior for a bad job_biz_id is left unaddressed.

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 0%, so the schema carries no semantics for job_biz_id. The description compensates by specifying the parameter's provenance (it comes from search results) and its expected form as an ID string, which is exactly what an agent needs to source it correctly.

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: read the complete JD for a given job_biz_id, plus its intended downstream use (岗位分析). This clearly separates it from yupao_search_jobs, though it does not name that sibling 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?

The phrase '根据搜索结果的 job_biz_id' implies the prerequisite that this tool is used after a search, but there is no explicit when-to-use/when-not guidance and no named alternative when the caller already has a full JD.

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/non-destructive/openWorld, but the description adds real behavior: results are paginated, only already-synced conversations are readable, reading does not trigger read receipts, and attachment download URLs are omitted from results. These are meaningful side-effect disclosures beyond the annotations.

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?

A single front-loaded sentence with the core action first and exclusions after; every clause earns its place 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?

No output schema and 0% parameter coverage mean the description should explain the cursor parameter and at least sketch the returned message shape; instead it omits both, leaving an agent unsure how to page or what fields come back.

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% for both parameters, so the description must compensate, yet it never explains conversation_id's origin or how next_req_message_id acts as a pagination cursor (where it comes from, how to continue). It only says 'paginated' generically.

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: paginated read of synced conversation chat history. The negative clauses ('does not send messages or read receipts') distinguish it from send/prepare_message siblings, though no sibling is named directly.

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 usage (read history of an already-synced conversation) and lists what it won't do, but never says when to call it versus alternatives like yupao_list_conversations to obtain a conversation_id or yupao_check_messaging_session.

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 cover readOnly/openWorld/non-destructive, and the description adds genuinely new behavioral context: it syncs via the official SDK, requires the chat dependency, and notably does NOT mark messages as read. These are meaningful traits beyond structured fields, though return format and pagination remain undisclosed.

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?

A single front-loaded sentence with three clauses, each carrying distinct information (sync source, default exclusion, no read-marking). Zero waste.

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 read-only list tool with no output schema, the description conveys enough to call it correctly but omits pagination semantics for limit/offset and any sense of the returned structure. Adequate but with clear gaps around the parameters.

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. It only explains the include_system behavior ('默认排除系统助手'), leaving limit and offset entirely undocumented in both schema and description. Partial compensation is insufficient for a list tool with 3 paginated parameters.

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 (sync/list conversations) and resource (conversations + HR contact profiles), which distinguishes it from yupao_get_messages. It's clear what the tool does, though it doesn't explicitly name a sibling alternative to route the agent.

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 usage (requires the chat dependency, excludes system assistants by default) but never states when to use this over yupao_get_messages or yupao_check_messaging_session. The prerequisite note is useful but not an explicit when/when-not guideline.

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?

The annotations already declare that the tool is a safe read operation (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds limited but real behavioral context: results are sorted, saved JD entries are flagged as updated, and the score is explicitly not a hiring probability, which is a useful expectation to set. However, it does not mention pagination, the default limit of 100, or what the data reflects locally.

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 a single compact sentence with a front-loaded action. Every part carries information: it states the action, the sorting, the update flag, and the caveat about scores. There is 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 read-only listing tool with no output schema and rich annotations, the description largely covers what the tool returns: match analyses and JD-update flags. The main gap is that it does not explain the two undocumented parameters, so an agent cannot know how to filter results by job or control the result count.

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 carries the full burden of explaining the two parameters, both of which lack any description in the schema. The description does not mention 'limit' or 'job_biz_id' at all, so an agent could not infer the meaning of 'job_biz_id' (a filter by job) or the default cap of 100 results.

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 uses a specific verb and resource: '读取和排序本机匹配分析' (read and sort local match analyses). That clearly distinguishes this read-only listing tool from its siblings yupao_prepare_match and yupao_record_match, which prepare or create matches. The purpose is clear, though the scope (all matches vs. filtered by job) is not stated 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?

The description gives no guidance on when to use this tool instead of yupao_prepare_match or yupao_record_match. It never states when this listing should be preferred, nor when it should not be used. Only the phrase '读取' implies a listing use 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=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description reinforces the no-network trait (useful but largely duplicative of openWorldHint=false) and says nothing about what is returned or whether presets persist between sessions.

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?

A single short sentence with the core action front-loaded and the scoping caveat second. No filler or restatement of the tool name.

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 could usefully say what a returned preset looks like (names, IDs, search criteria) or that an empty list is possible. For a 0-parameter local read tool this is minor, but the return shape is left entirely 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?

Zero parameters with 100% schema coverage, so there is nothing for the description to disambiguate. Baseline 4 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 ('读取本机保存的搜索预设' – read locally saved search presets) and adds a scope qualifier ('不请求鱼泡') that separates it from network-touching siblings like yupao_search_preset. It never names those siblings directly, so differentiation is implicit rather than explicit.

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 'local only, no network request' clause implies when to prefer this over yupao_search_preset (e.g., offline or avoid session requirements), but the choice is left to inference. There is no explicit 'use this when… / use X instead when…' statement.

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 and destructive=false; the description adds that only metadata is returned and that no download/send occurs, which is meaningful behavioral context beyond the annotations. Return field details are absent but the safety profile is well covered.

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 compact sentences with the main purpose front-loaded and the param hint plus negative scope following directly. 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 simple read-only single-param listing tool with no output schema, the description covers purpose, param meaning, and what is not done. It could mention what metadata fields are returned, but that is a minor gap against annotations that already carry the safety profile.

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?

With 0% schema coverage, the description carries the param burden and does so: it explains that for_chat=true targets chat attachments, complementing the schema's default of false. One param, one clear semantic addition.

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 (list) and resource (uploaded resume attachment metadata) with an explicit scope of '本人已上传'. The negative clause clarifies it is not a download/send tool, though no direct sibling is named for differentiation.

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?

Explains that for_chat=true selects chat attachments and explicitly states it does not download or send resumes, giving clear when-to-use context. It stops short of naming an alternative tool for downloading or sending, but the scope is unambiguous.

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?

The annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are known. The description reinforces this with '不请求平台', which is consistent and mildly useful, but it omits any behavioral detail such as whether an empty result means no saved jobs, how limit truncates, or whether the data can be stale relative to the platform.

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?

A single compact sentence with no filler, and the filter information is front-loaded before the locality note. It is efficient, though the terseness comes partly from omitted information rather than discipline.

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 three undocumented parameters, no output schema, and no enum constraints, an agent cannot know what valid tag/status strings are or what limit does. The description does not fill that gap.

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 all three parameters must be explained here. The description covers tag and status only at the level of naming them, and says nothing about the limit parameter (default 100) or accepted tag/status values (no enums in 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?

The description names the resource (本机候选池, the local candidate pool) and two filters (tag, status), and the 'does not request platform' clause signals it is a local read. However, it never says this returns *saved jobs*, so the relationship to the tool name and to the sibling yupao_list_matches remains ambiguous.

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?

There is no indication of when to pick this over yupao_list_matches or yupao_search_jobs, nor any prerequisite. The only usage-adjacent signal is that it works offline against the local pool.

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 supply the safety profile (destructiveHint=false, openWorldHint=true), and the description usefully clarifies that no communication or application is actually sent. But readOnlyHint=false implies some server-side state change during 'preparation', and the description's '预览' framing never reconciles that tension or says what, if anything, gets persisted.

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?

A single dense sentence with the scope and the non-mutating guarantee front-loaded; no filler. It is arguably too short for the amount of undocumented behavior it must carry.

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 and 0% parameter documentation, the description carries the full burden. It does say what the preview returns (publisher, resume, permissions) and what it does not do, but omits identifier sourcing and permission-failure behavior, leaving real gaps for a two-param tool.

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% for both parameters, so the description must compensate. It only alludes to '指定附件' (the resume_file_id) and says nothing about job_biz_id — its format, source, or whether it comes from yupao_search_jobs results — nor about the empty-string default on resume_file_id.

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?

A clear verb (预览/prepare-preview) plus a specific resource (单条指定附件投递 — a single application with a specified attachment resume), and it lists what the preview surfaces (publisher, resume, permissions). It is distinguishable from the mutation siblings like yupao_execute_action, though the 'prepare' prefix family (prepare_match, prepare_message) is not explicitly contrasted.

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?

'准备阶段不发起沟通或投递' signals this is a dry-run/preflight step, which implies 'use before committing'. However, it never names the follow-up tool (e.g. yupao_execute_action) or states when a preview is unnecessary, so the routing decision is left to inference.

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=false and destructiveHint=false, so the write nature is known. The description adds genuine context beyond annotations: that it does not call an external model and that it emits citation requirements. It still omits where materials are stored, side effects, and what the generated output contains.

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?

A single front-loaded sentence that opens with the primary action and packs the non-model-call caveat and citation-requirements detail without filler. Efficient and appropriately sized.

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 a mutating tool with no output schema, 0% schema coverage, and 3 parameters. The description leaves profile_name undocumented and never explains the generated materials/citation structure or the persisted side effects, so it is not complete enough for an agent to invoke confidently.

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 carry parameter meaning. It loosely maps '完整 JD' to job_biz_id and '简历材料' to resume_text, but gives no format or constraints, and profile_name (with default 'default') is never mentioned at all.

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 specific verbs (保存/generate) and a specific resource (full JD plus user-provided resume materials), and adds that it produces materials and citation requirements for the host AI. This clearly distinguishes it from record_match (which would persist results), though it does not name 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: it is a preparation step that readies material for the host AI to analyze ('供当前宿主 AI 分析'), with '不另调模型' clarifying that it does not invoke a model. However, it never states when to use this versus alternatives like record_match or prepare_application, nor any exclusions.

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 establish destructiveHint=false and openWorldHint=true, so the bar is lower, and the description usefully adds that nothing is sent at this stage plus a constraint about verifying association for existing threads. It omits what is persisted or returned by the preparation step, and "预览" sits in mild tension with readOnlyHint=false if it does create a prepared record.

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 compact clauses with the core action front-loaded and zero filler. Brevity shades into obscurity in spots, since "须核验关联" is terse to the point of being unclear, but nothing is wasted.

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 a non-read-only tool with no output schema and four undocumented parameters, so the description carries the full burden — yet it never says what the preparation returns (an id? previewed content?) that the agent would need in order to execute it later. For a two-stage prepare/execute flow, that is a substantial gap.

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% — all four parameters carry only titles — so the description must compensate and largely does not. It does explain start_conversation's meaning (free first chat) and gestures at conversation_id via the association-verification clause, but job_biz_id (where it comes from) and text are undocumented anywhere.

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 ("预览单条消息" — preview a single message) and removes the biggest ambiguity by declaring "准备阶段不发送" (preparation does not send). It does not differentiate itself from siblings such as yupao_execute_action, which presumably consumes the prepared message, so an agent cannot fully route between them from this text alone.

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 conditional guidance for two cases: existing conversations require association verification, and start_conversation=true covers the free first-time chat. However it never names an alternative tool or says when NOT to use this one, and the path from preview to actually sending (yupao_execute_action) is left implicit.

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 a non-read-only, non-destructive, closed-world write. The description usefully adds that validation of citations occurs and that 'unknown' is distinct from 'not satisfied' — real behavioral context. It does not say what happens when validation fails (reject, repair, or store anyway) or whether re-recording overwrites prior analysis, which are the biggest open questions for a write 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?

A single dense sentence that front-loads the action and then the processing behaviors. Nothing is wasted, though the two clauses are separated only by a semicolon, making it easy to skim past the behavioral detail.

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 a nested, undocumented object payload, no output schema, and only 0% schema coverage, the description should define the analysis object's expected contents and the validation outcome. It hints at these but leaves an agent unable to call the tool correctly without trial and error.

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% and the core parameter `analysis` is a free-form nested object with additionalProperties:true, so the schema provides essentially no guidance. The description gestures at the payload's semantics (per-item analysis, citations, unknown vs unmet, weighted aggregation) but gives no field names or structure, leaving the agent to guess the object shape.

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 gives a concrete verb+resource: persisting the host AI's item-by-item match analysis, plus the extra processing it performs (validating JD/resume citations, separating unknown from unmet, aggregating weights). This separates it from yupao_list_matches and yupao_prepare_match, though 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?

The phrase '宿主 AI 的逐项匹配分析' implies it is called after analysis has been produced (i.e., downstream of yupao_prepare_match), but no when/when-not condition or alternative is stated. An agent can infer the lifecycle position but not the boundaries.

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?

The description says the tool removes a preset and only affects the local machine, but the annotations declare destructiveHint=false. Since removing a saved preset is a deletion of local persisted data, this directly contradicts the non-destructive annotation.

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 a single front-loaded sentence with no wasted text. It is appropriately terse for a simple one-parameter tool, though the terseness contributes to missing behavioral and parameter detail.

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 mutation tool with one undocumented parameter and no output schema, the description should clarify success/failure behavior and deletion semantics. It states the local-only scope, but the destructiveHint contradiction and missing parameter semantics leave important gaps.

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 one required parameter, name, with 0% schema description coverage. The description implies that the parameter identifies the preset to remove, but it does not clarify matching behavior, exactness, or what happens if the name does not exist.

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 and resource: removing a specified local search preset. It also scopes the action to the local machine rather than the platform, which helps distinguish it from platform-side operations, though it does not explicitly name sibling preset 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?

Usage is implied by the verb 'remove' plus the local-preset scope, but the description does not say when to use this versus save_preset, search_preset, or list_presets, nor does it state prerequisites or exclusions.

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 indicate this is not read-only but also not destructive in the platform sense. The description adds valuable behavioral context by clarifying that removal is local and does not undo platform submissions or communications, which aligns with destructiveHint=false and prevents a serious misunderstanding.

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?

One short sentence, front-loaded with the core action and immediately followed by the key scope clarification. There is no wasted wording.

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 one-parameter removal tool, the description covers purpose and important non-effects, but it leaves the only parameter undocumented and does not describe what a successful removal returns or how to obtain the job_biz_id. Given no output schema and zero parameter coverage, this is only minimally complete.

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 sole parameter job_biz_id has 0% schema description coverage, and the description does not mention it or explain its format, source, or meaning. The phrase '指定' implies a specific job must be identified, but provides no compensating semantics for the undocumented parameter.

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: remove a specified local candidate job. It also clarifies that this does not revoke platform applications or communications, which meaningfully scopes the operation, though it does not name sibling tools that could be alternatives.

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 implicitly says when to use it by describing the operation as local saved-job removal and explicitly excludes platform application/communication changes. However, it does not provide explicit when-to-use guidance versus related tools like yupao_save_job, yupao_list_saved_jobs, or yupao_remove_preset.

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=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered; the description adds genuinely useful behavior beyond that by disclosing dedupe by job_biz_id and preservation of note/tags. It stops short of saying what happens when the job is already saved (overwrite vs merge of existing note/tags), which is the key ambiguity for a repeat call.

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?

A single compact sentence with the primary action front-loaded and no filler. The density is high but each clause (full JD, local pool, dedupe key, note/tags) contributes distinct information.

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 3-parameter mutation with no output schema and zero schema description coverage, the description should say what a successful call returns (e.g., saved record id or created-vs-existing flag) and confirm whether tags/note replace prior values. Those gaps remain, though the core action and dedupe semantics are covered.

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 carries the burden, and it does name all three parameters in effect: job_biz_id as the dedupe key, plus note and tags as preserved values. It adds no format, length, or defaulting detail (tags nullable, note defaulting to empty), so it partially but not fully compensates for the schema gap.

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 concrete verb and resource: it reads the full JD and writes it into the local saved-job pool, with dedupe key and preserved fields called out. That is enough to distinguish it from yupao_list_saved_jobs or yupao_remove_saved_job, though it never explicitly contrasts itself with the nearby yupao_annotate_job, which also touches note/tags.

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?

There is no statement of when to call this instead of yupao_get_job_detail (which also fetches the JD) or yupao_annotate_job (which also manages note/tags), and no prerequisites or preconditions are given. Usage is only inferable from the verb 'save'.

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=false, destructiveHint=false, and openWorldHint=false, so the mutation and safety profile are partly covered. The description adds that unverified platform filters run locally ('平台未核实的过滤在本机执行'), which is useful behavioral context, but it does not explain persistence, overwrite behavior, or whether an existing preset name is replaced.

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 definition is compact and front-loaded, with purpose stated first and parameter semantics following. It is efficient, though the terse phrasing leaves important behavior implicit.

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 mutation tool with 10 parameters and no output schema, the description is incomplete. It omits key details such as whether the preset requires a unique name, whether saving overwrites an existing preset, what is returned, and session requirements.

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% with 10 parameters, so the description must carry the burden. It clarifies salary units ('元/月') and that education/experience refer to the person's own conditions, but leaves name, keywords, excluded_terms, required_terms, page_size, and city semantics undocumented.

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 a specific verb and resource: '保存搜索条件' (save search criteria). It is distinguishable from siblings like yupao_search_preset, yupao_list_presets, and yupao_remove_preset, though it does not explicitly name or contrast them.

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?

There is no guidance on when to use this tool versus alternatives such as yupao_search_jobs or yupao_search_preset. It also does not state prerequisites, exclusions, or typical scenarios for saving a preset.

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, openWorldHint=true, and destructiveHint=false. The description adds useful behavioral context by stating it searches in real time, returns paginated structured results, and will not apply or greet, which reinforces the safe read-only nature of the 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?

The description is two short sentences with no wasted language. The core purpose and the non-action constraint are front-loaded and easy to scan.

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?

The description covers the basic search behavior and explicitly rules out application/greeting side effects. For a search tool with four parameters, no schema descriptions, and no output schema, it could do more to explain pagination behavior, defaults, and result characteristics.

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 carry parameter meaning. It mentions keyword and city search as well as pagination, which maps conceptually to all four parameters, but it does not explain defaults, page-size limits, or expected formats.

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 and resource: real-time job search by keyword and city. It distinguishes itself from action-oriented siblings by explicitly saying it will not apply or greet, though it does not explicitly separate itself from detail or saved-job 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 implies the tool is for searching jobs and clarifies that it performs no application or greeting actions. However, it does not explicitly state when to use this instead of alternatives such as getting job details or listing saved jobs.

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 and destructiveHint=false, so the description's job is to add operational context, which it does: it discloses that each page yields at most 10 full JD reads and that unmatched criteria are surfaced separately as items to verify. That volume pacing and the 'unknown conditions' handling are real behavioral traits not present in the annotations.

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 tight clauses separated by a semicolon, with the core action front-loaded and no filler. Density comes at some cost to parseability for non-Chinese readers, but every clause carries information.

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 should say more about what comes back (a result list plus a separate unresolved-criteria bucket is only hinted at via '单列待核实'). It also omits prerequisites such as session validity or what happens if the named preset does not exist, which matters given the sibling yupao_check_session and yupao_list_presets tools.

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 bears the burden. It implies `name` is a preset identifier ('按预设') and that `page` controls paging with '每页最多 10 个详情', but it never explicitly defines either parameter, give the page-size constant in relation to the param, or state whether page is 1-indexed.

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 ('按预设搜索' = search by preset) plus concrete follow-on behavior (reads full JD, local filtering). An agent can tell this is a preset-driven search rather than a raw keyword search, though the distinction from the sibling yupao_search_jobs is never made explicit.

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 phrase '按预设' implies the precondition that a preset must exist (matching the required `name` param), and '读取完整 JD 后本机筛选' implies this is the heavyweight search to use when local filtering of full postings is wanted. But there is no explicit when-to-use, no exclusions, and no pointer to yupao_search_jobs or yupao_list_presets as alternatives.

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