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

No annotations are provided, so the description carries the full behavioral burden. It discloses a key migration fact (jdText is renamed to jd) but omits whether the tool is deprecated, whether it is safe to use alongside application_add, and any side effects of creating a record. This is minimal behavioral context for a mutation 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 short sentence that front-loads the essential alias relationship. It is appropriately sized and wastes no words, though it could have used the space to say more since it is so brief.

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 4-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, this description is incomplete. It covers only the rename mapping and omits required parameters, behavior, and deprecation guidance.

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 maps one parameter (jdText -> jd) and says nothing about company, jobTitle, or status, including their required/optional status. Three of four parameters are left undocumented in both schema and description.

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 this is a legacy alias equivalent to application_add, which is a specific mapping, but it never says what the tool actually does in functional terms (add an application record). It relies entirely on the reader knowing what application_add does. This is clearer than a pure tautology but still vague on purpose.

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 implies when to use it: only as a backwards-compatible alias for application_add. However, it does not explicitly say 'use application_add instead and avoid this' nor when-not-to-use it, leaving the agent to infer deprecation status.

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?

No annotations are provided, so the description carries the full behavioral burden. '查看' implies a read-only retrieval, but nothing is stated about ordering, pagination, scope of history, or what happens when no history exists. For a no-annotation tool this leaves meaningful gaps.

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 zero filler. The resource being retrieved is stated immediately and nothing is 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 zero parameters and no output schema, the description must tell the agent what comes back. It names the two record types (gap analysis reports, learning paths) but gives no sense of the fields, format, or volume of the returned history, leaving the return surface partly opaque.

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 per the rubric the baseline is 4. There are no parameter semantics to add, and the description does not misrepresent the input surface.

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 clear verb+resource: '查看' (view) historical '短板分析报告' (gap analysis reports) and '学习路线记录' (learning path records). This distinguishes it from sibling generators like gap_analysis and learning_path_generate, which produce rather than retrieve these artifacts. It is clear, though it does not explicitly name those siblings.

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 word '历史' (historical) — use this to look back at previously generated reports and paths. However, there is no explicit when-to-use/when-not guidance and no reference to the alternative generation tools an agent might confuse it with. Adequate but with a clear gap.

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?

No annotations are provided, so the description carries the full burden. It says the tool records an application but discloses nothing about mutation behavior: whether duplicate applications are allowed, what happens on invalid input, what side effects occur, or what is returned. The schema's status default (已投递) is never echoed or explained.

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 front-loaded sentence with the verb and resource first and the field list in parentheses; zero waste. It is efficient, though borderline under-specified rather than genuinely optimized.

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 8 parameters, no annotations, no output schema, and a plausible duplicate sibling, the description is too thin. It omits duplicate/validation behavior, defaults, and any disambiguation from add_application_record, leaving real gaps an agent would need filled.

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 50%, and the description names most fields (company, position, JD, status, channel, salary, notes), which roughly maps to the schema. However, it adds no semantics beyond the property names — no formats, ranges, or optionality — and omits matchScore entirely, so it only marginally compensates for the coverage 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?

States a specific verb (记录/record) and resource (一次岗位投递/a job application), plus enumerates the captured fields. The purpose is unambiguous in isolation, but the description never acknowledges the apparent near-duplicate sibling add_application_record, so an agent cannot tell the two apart from the text.

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, no preconditions, and no reference to alternatives such as application_update or the confusingly similar add_application_record. Usage context is only vaguely implied by the verb 'record'.

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?

With no annotations, the description carries the full behavioral burden for a destructive operation. It never says whether the delete is permanent or soft, whether confirmation is needed, what permissions are required, or what happens when the id does not exist.

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 or repetition. It is efficiently sized for the operation, though there is essentially no structure to evaluate.

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 destructive, unannotated, single-parameter tool with no output schema, the description omits irreversibility, error behavior on unknown ids, and authorization requirements. An agent can call it, but not with confidence about consequences.

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% and the schema only types id as a string. The phrase "按 id" does tell the agent that id is the record identifier used for deletion, adding some meaning beyond the schema, but gives no format, source, or validity details to compensate for the total coverage 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 states a specific verb (删除) and resource (投递记录) scoped by id, which is enough for an agent to distinguish it from application_add, application_list, and application_update. It stops short of explicitly contrasting itself with any sibling, so it lands at a clear-but-undifferentiated 4.

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 when-to-use guidance, no prerequisite or alternative named, and no indication of when deletion is appropriate versus application_update. The description only restates the operation.

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?

With no annotations, the description carries the full behavioral burden. It implies a safe read via 列出 and discloses the filter dimensions, but says nothing about pagination, default ordering, result limits, or whether all records are returned by default.

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 zero-waste sentence that front-loads the operation and then the filter options. Nothing is padded or 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?

For a simple two-parameter list tool with no output schema and no annotations, the description covers the operation but omits result-shape expectations (ordering, pagination, empty results) that an agent would need to call it 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 50%: keyword is documented in-schema ('按公司/岗位模糊匹配') and status is a self-explanatory enum. The description only restates that both filters exist, and its '公司关键词' wording is actually narrower than the schema's company/position matching.

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 the filtering capability makes it clearly a query/list tool rather than a mutation. It does not name any sibling, but the read-only listing intent is unambiguous against application_add/update/delete.

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 says filtering by status or keyword is possible but never states when to use this tool versus application_stats (aggregates) or job_archive_list (archived postings). No prerequisites, exclusions, or alternatives are mentioned, leaving routing 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?

No annotations are provided, so the description carries the full behavioral burden. It says what metrics are computed but never states that the operation is read-only, what scope/timeframe the stats cover, how fresh the data is, or what the response shape looks like — significant gaps for a tool with zero annotation coverage.

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 tight sentence that front-loads the resource and then lists the computed metrics; every clause earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and no output schema, the description partly compensates by enumerating the returned metrics (status counts, conversion rate, average match score). It is close to sufficient for a zero-arg read tool, though the lack of any scope or time-window note leaves a small 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?

The tool takes zero parameters, so there is no parameter syntax to document; per the rubric this earns the baseline 4. The description correctly implies no filtering inputs are required.

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 metrics returned (各状态数量、转化率、平均匹配分), so the agent knows this is an aggregate-stats tool, not a record listing. It is distinguishable from application_list by being a funnel summary, though it never names the 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 purpose implies usage (call this to see funnel/conversion metrics), but there is no explicit when-to-use statement, no exclusions, and no reference to alternatives like application_list for per-record data. Usage is only inferable.

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?

With no annotations, the description carries full burden. It does disclose one valuable side effect: 状态变更会自动写入历史 (status changes auto-write history). But it omits permissions/auth needs, whether unspecified fields are preserved or cleared, and whether updates are reversible or partial.

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 the notable side effect second. No filler, though it is arguably too terse given the 6-parameter surface.

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 zero annotations, no output schema, and 6 undocumented parameters, the description is thin. It covers the status history side effect but leaves update semantics, the enum, and the other three fields entirely to the schema, which provides no descriptions either.

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 6 params, so the description must compensate but only names 3 of 6 (status/notes/salary). It says nothing about channel, matchScore, or id, and gives no meaning for the 11-value status enum that the agent must choose from.

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 mutable fields (状态/备注/薪资), making it distinguishable from application_add/application_list/application_delete. However, it doesn't explicitly name or contrast with those siblings, so the differentiation is implied rather than stated.

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 to use this versus application_add or add_application_record, no prerequisites, and no mention of the partial-update nature (only id is required) despite 5 optional fields. The agent must infer all usage 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that this is a read/analysis operation whose result is 'embeddable optimization text' rather than a mutation of the resume, and it enumerates the four output artifacts in the absence of an output schema. However, it says nothing about auth needs, whether the resume is pulled from session state, or rate/cost constraints.

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 well-formed sentence, front-loaded with the action and then the delivered artifacts. Nothing is redundant, though the trailing artifact list makes it slightly dense.

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 annotations, the description partly compensates by naming the four outputs, which is genuinely helpful. It still leaves gaps for a resume-analysis tool: where the resume comes from, whether anything is persisted, and any failure/permission behavior are 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?

One required parameter (jdText) at 0% schema coverage, so the description must compensate. It implies the JD is supplied as text and that the resume side is implicit ('当前简历'), giving partial semantic grounding, but it adds no format, length, or syntax detail beyond that.

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: performs an ATS keyword-coverage check on the current resume against the JD, and enumerates the outputs (keyword extraction, coverage stats, high-risk loss items, embeddable optimized text). An agent can tell what it produces, though it does not explicitly distinguish itself from near-neighbors like resume_score_match or resume_rewrite.

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 says what the tool does but never says when to reach for it versus the many related siblings (resume_score_match, resume_rewrite, gap_analysis). No prerequisites, no exclusions, no alternative routing guidance.

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?

No annotations are supplied, so the description carries the full behavioral burden, and it discloses almost nothing: no statement of whether a stored profile/resume is read implicitly, no auth or quota notes, and no indication of what the generated letter looks like. For a generation tool with zero annotation coverage this is a 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?

One compact sentence with the action and inputs front-loaded and no filler. It is efficient, though the brevity is partly under-specification rather than disciplined concision.

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 annotations, no output schema, and no explanation of how the resume is sourced or what is returned, the definition is too thin for a generation tool. An agent cannot tell whether a resume must be loaded first, whether the call is safe/idempotent, or what the result contains.

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 75% (tone, company, jobTitle documented), so the schema does most of the work. The description adds only marginal meaning: '基于简历与 JD' hints at the undocumented jdText input and '支持指定语气风格' echoes the tone parameter without defining valid values or a default beyond what the schema says.

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 (生成定制求职信) plus the two inputs it operates on (简历与 JD), which lets an agent distinguish it from resume_rewrite and ats_optimize. It stops short of naming any sibling it is not, so differentiation is inferred 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 description implies prerequisites (you need a resume and a JD) but gives no when-to-use/when-not guidance and never names an alternative such as resume_rewrite or resume_score_match. An agent must guess at routing among the many resume/interview siblings.

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?

No annotations, so the description carries the full burden; it usefully discloses that the operation is local-only and does not upload, which is valuable for a data-export tool. However, it omits other behavioral facts such as whether existing files in the target directory are overwritten or how the result is reported.

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, front-loaded with the action and scope, and the local-only caveat placed second. 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 low-complexity, one-optional-param export tool with no output schema, the description covers purpose, scope, and the privacy-relevant local-only behavior. Only minor gaps remain (overwrite behavior, return value), which are acceptable at this complexity.

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 optional parameter has 100% schema description coverage including a documented default path, so the schema does the heavy lifting. The description adds no syntax or format detail beyond what the schema already provides, so 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: copy all local JSON data to a target directory, with the purpose (backup/migration) named. An agent can distinguish it from data_info, but it does not explicitly contrast with resume_export, the other export 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?

Gives implied usage (备份或换机迁移), which is reasonable context, but names no alternatives and no explicit when-not conditions (e.g. use resume_export for a single resume).

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?

With no annotations, the description carries the full behavioral burden. '查看' implies a read-only, non-mutating operation and the description discloses what information is surfaced (location, generation status, counts, privacy policy), which is helpful. It does not explicitly confirm read-only safety or whether it touches/moves data, so it is adequate but not rich.

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 tightly packed sentences: the first enumerates the outputs, the second gives the usage cue. Front-loaded and 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 exists, so the description must describe returns – and it does (where data lives, whether files are generated, approximate counts, privacy policy). For a zero-param informational tool this is close to complete, though it doesn't clarify the response structure or freshness of the counts.

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. There are no parameter semantics to clarify, and the description correctly implies no input 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 (查看) and concrete resources: data storage location, per-file generation status, record counts, and privacy policy. This is clearly distinguishable from siblings like data_export or jobok_workflow, which do different things.

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?

Adds one usage context ('换机前可先看这里' – check here before switching machines), which implies a pre-migration scenario. However, it never names when NOT to use it or points to an alternative (e.g., data_export for actually extracting data), leaving the choice 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?

No annotations are provided, so the description carries the full behavioral burden. It partially compensates by describing the output content (radar, TOP5, strengths, actions), which is valuable given there is no output schema, but it does not state side effects, whether it is read-only, persistence behavior, or permission requirements.

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, front-loaded with the core purpose and then the follow-up recommendation. No filler. It could be marginally tighter but every clause contributes.

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 or annotations, the description does the work of naming the return content, which is the key missing piece. The remaining gap is the undocumented targetRole parameter, but overall an agent has enough to invoke 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?

Schema description coverage is 50%: jdText is documented as optional with fallback behavior, but targetRole has no description anywhere. The description references 'resume vs target JD', loosely mapping to jdText, but adds no meaning for targetRole and no format or syntax 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?

Names a specific action (capability inventory + gap analysis) on a specific resource (current resume vs target JD) and enumerates the concrete outputs (capability radar, TOP5 shortfalls, transferable strengths, action items). It is clear as a standalone statement, though it does not differentiate itself from potential overlap with resume_score_match or job_score_match.

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?

Provides a workflow hint by recommending recording the shortfalls before calling learning_path_generate, which implies usage context. However it never states when to choose this tool over close alternatives like resume_score_match or job_score_match, nor any 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?

No annotations are provided, so the description carries the full behavioral burden, yet it only asserts equivalence to another tool. It says nothing about latency, model invocation, side effects, or return content, and provides no indication of whether the alias is preferred or discouraged.

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 that front-loads the two most useful facts (legacy status, equivalence). Nothing is padded, though it is arguably under-specified rather than ideally concise.

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 compatibility shim the description supplies the key redirect target, which is the most important thing here. However, it omits any explicit deprecation guidance and any meaning for jdText, so an agent still lacks a clear instruction on which tool to prefer.

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 parameter (jdText) with 0% schema description coverage, and the description adds no explanation of it whatsoever. The parameter name is self-suggesting, but the description does nothing to compensate for the missing schema documentation.

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 this is a legacy alias and names its canonical equivalent (interview_question_bank), which is genuine routing information an agent can act on. Combined with the name and title it is clear this generates interview questions, but the description itself does not restate the actual function, so it stops short of a clean 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?

Naming the equivalent tool implies the two are interchangeable and hints that the canonical tool is preferred, but there is no explicit deprecation directive or condition for choosing one over the other. Usage is only implied, 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the structure of the generated content (six categories plus TOP5 and coping strategies), which is genuine value. But it says nothing about determinism, whether results are persisted, whether a saved resume is required, or the shape of the response, leaving real gaps for a no-annotation 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 well-formed sentence that front-loads the core action and then lists deliverables. Dense but every clause conveys a real content category. Slightly list-heavy, but no wasted prose.

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 annotations, the description does partially compensate by describing the generated content. However, it omits the return format, whether output is persisted, and how the 'resume' input referenced in the text is actually supplied, given the schema exposes only jdText. 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?

Schema description coverage is 100%, so count, level, and jdText are already documented in the schema. The description mentions basing output on JD and resume, but 'resume' is not an input parameter, and it adds no semantics for count or level beyond what the schema states. 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 enumerates the coverage areas (基础原理, 项目深挖, 领域专项, 工程化, 安全, 软技能) plus extra deliverables (TOP5, 应对策略). This is far more concrete than a tautology. However, it does not differentiate from the very similar sibling generate_interview_question, which an agent could easily confuse it with.

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 use this tool versus alternatives such as generate_interview_question or mock_interview_start, and no prerequisites are given. Usage must be inferred purely from the name and content 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully enumerates the report output (per-question diagnosis, optimized answers, weakness ranking, prep checklist), which tells the agent what a call yields. It does not state whether anything is persisted, whether the report is retrievable later, or any input limits — meaningful gaps for a tool with zero annotation coverage.

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 action first and the report contents compactly listed in parentheses. No filler, no redundancy with the title, nothing that fails to earn its place.

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 compensates by enumerating what the generated report contains, and the input surface is small and simple (1 required, 1 optional). The remaining gap is behavioral: persistence, retrieval, and length/size constraints are unaddressed, but for a one-shot analysis tool this is close to 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?

Schema description coverage is 100%, so both chatLog and the optional jdText are already documented in the schema, making 3 the baseline. The description adds no additional parameter meaning — it never mentions the optional JD parameter, which visibly shapes the quality of a review, so it does not improve on the structured data.

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: paste an interview transcript and generate a deep review report, with the report's components enumerated in parentheses. It clarifies the tool accepts either real or mock interview logs, which separates it from the live mock_interview_* tools. It does not, however, distinguish itself from the sibling interview_summary, which an agent could reasonably confuse it with.

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 rather than stated: '任意一场真实/模拟面试的对话记录' signals a post-interview, transcript-in-hand scenario. There is no explicit when-to-use, no exclusion, and no named alternative (e.g. interview_summary) to route the agent. Adequate but leaves the agent to infer selection.

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?

No annotations are provided, so the description carries the full behavioral burden. The only behavioral fact disclosed is equivalence to interview_review; it says nothing about whether this alias is deprecated, still functional, or will be removed, nor about required inputs or side effects.

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, front-loaded sentence with no filler. It is appropriately sized for a compatibility shim, though brevity here reflects under-specification rather than disciplined editing.

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 tool with no output schema and no annotations, the description should at minimum explain the parameter and clarify deprecation status. Pointing at interview_review is a start but leaves the agent unable to invoke this tool meaningfully on its own.

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 sole required parameter (chatLog) is undocumented in both schema and description. The description should have explained what chatLog expects (e.g., an interview transcript), but adds nothing.

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 identifies the tool as a legacy alias equivalent to interview_review, which gives the agent an indirect route to purpose. However, it never states what the operation actually does (an interview debrief/review over a chat log), so an agent that doesn't already know interview_review learns nothing about the resource or action.

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?

"旧版工具名，等价于 interview_review" implies this is the deprecated/compat name and that interview_review is the canonical alternative. That is useful routing context, but it never explicitly says 'prefer interview_review' or states any condition for choosing one over the other.

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?

No annotations are provided, so the description carries the full behavioral burden. It says the job is archived/bookmarked, but not whether a duplicate archive is created, whether anything is overwritten, what permissions are needed, or what the write returns — all material for a mutation 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 front-loaded sentence with no filler; the purpose and the usage condition arrive immediately. It is arguably undersized for a 6-parameter mutation tool, but nothing in it 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?

For a mutation tool with no annotations, no output schema, and 33% parameter coverage, the description should explain duplicate handling, required inputs like the full JD, and the resulting state. It stops at the one-line purpose, leaving real 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?

Schema description coverage is only 33%: tags and source are documented in the schema, while jd, company, jobTitle and matchScore are undocumented anywhere. The description adds no parameter meaning at all, so it fails to compensate for the coverage 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?

States a specific verb+resource (把感兴趣的岗位加入归档) plus the intent (收藏/长期跟踪), so an agent knows it persists a job for tracking rather than applying. It does not name the sibling it contrasts with, but the '尚未投递' qualifier implicitly separates it from job_archive_to_application.

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 a genuine when-to-use condition, which is more than most siblings offer. However, it never names an alternative (e.g. job_archive_to_application, application_add) or states when NOT to use it, leaving the routing 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?

No annotations are supplied, so the description carries the full behavioral burden, and it discloses nothing about irreversibility, whether the deletion cascades to linked applications or history, or what the response confirms. For a destructive mutation tool this is a significant disclosure gap; it is at least not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence that front-loads the key constraint (deletion keyed by id) with no filler. It is efficient, though the brevity is partly a symptom of under-specification rather than disciplined writing.

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 destructive tool with no annotations, no output schema, and zero parameter documentation, the description leaves the agent without the safety context needed to call it correctly. It does not say the operation is permanent or what happens to dependent records.

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 parameter is documented only as a bare string with no description. The description adds only that the id identifies the archived position, without noting where the id comes from (e.g., job_archive_list) or its format.

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 (删除/delete) and resource (归档岗位/archived job), and the id argument makes the targeting explicit. It is distinguishable from job_archive_add and job_archive_list by name and verb, though it never explicitly contrasts itself with 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 versus alternatives such as job_archive_to_application, nor any prerequisite or caution about deleting archived positions. The agent must infer usage purely from the name.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'all archived jobs' but does not state read-only status, authentication needs, pagination, ordering, or how the optional keyword affects results.

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 or redundancy. It is concise, though the brevity contributes to the missing usage and parameter details.

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, no annotations, and an undocumented parameter, the description is too thin to tell an agent what the tool returns, whether results are paginated, or how to use keyword filtering. It covers only the bare operation.

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 description never mentions the single optional 'keyword' parameter. The description says 'all archived jobs', which may even mislead an agent away from using the keyword filter.

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: '列出' (list) '归档岗位' (archived jobs). It implicitly distinguishes archived jobs from active jobs, but it does not name or contrast with sibling tools such as job_archive_add or job_archive_delete.

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?

Provides no explicit when-to-use, when-not-to-use, or alternative guidance. It only describes the operation itself, leaving the agent to infer when an archived-job listing is appropriate.

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?

With no annotations, the description carries the full burden and does disclose one useful behavioral trait: the source archive is retained (归档保留), implying no deletion of the original. However, it omits mutation-relevant facts such as whether a duplicate application is created, default status/channel behavior, and reversibility.

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 key action and the retention caveat front-loaded. Efficient, though its brevity is partly the source of the other gaps rather than pure economy.

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 annotations, no output schema, and low schema coverage, yet the description is one sentence. An agent lacks enough information about side effects, duplicate handling, and parameter meaning to call it 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 only 33%. The description says nothing about any of the three parameters: the enum-constrained 'status' has no explanation of defaults, and 'channel' is entirely undocumented in both schema and description. It fails to compensate for the coverage 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?

States a specific verb+resource pair: converting an archived job into an application record. This distinguishes it from generic siblings like application_add or add_application_record, which create records without an archived-job source. Clear, though it never names those alternatives 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 implies its use case (converting archived jobs) but gives no explicit when/when-not guidance and never mentions alternatives such as application_add. No mention of preconditions, e.g., what happens if the job is not archived or an application already exists.

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?

No annotations are provided, so the description carries the full burden, and it does disclose the complete payload of the call (onboarding steps, examples, cheat sheet, privacy notice), which makes the read-only, side-effect-free nature evident. It stops short of stating idempotency or cost/latency traits, but for a zero-parameter info tool this is adequate coverage.

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 clauses, front-loaded with the trigger condition, then the return contents, then a fallback cue. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must describe returns, and it does so item by item. For a 0-parameter onboarding tool with no annotations, nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter discussion, avoiding noise.

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 purpose (first-run onboarding) and enumerates exactly what it returns: a 4-step flow, copy-paste example prompts, a full tool cheat sheet, and a privacy statement. It is clearly distinct from data-oriented siblings like data_info or jobok_workflow, though it does not name them 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?

"第一次使用时调用" gives an explicit trigger condition, and "不确定该说什么时先看这个" adds a second, complementary one for confused agents. There is no explicit when-not guidance, but the first-use framing strongly implies it is not meant to be called repeatedly.

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?

With no annotations, the description carries the full burden. It does disclose the fallback behavior when scene is omitted and characterizes the return as ordered, copyable steps, which is real behavioral context. It says nothing about output format details, whether results are cached/static, or any constraints, leaving gaps for a tool with zero annotation coverage.

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 sentences with no filler. The core purpose is front-loaded, and the optional-parameter fallback follows immediately. Every sentence earns its place.

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?

There is no output schema, but the description compensates by characterizing the return (ordered tool-call steps and phrasing) plus the all-scenarios fallback. For a single-optional-parameter orchestration tool this is nearly complete, with only minor detail about output structure missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the enum of scene values is fully documented in the schema, so the baseline is 3. The description adds the meaningful omission semantics (omitting scene returns all scenarios), but this is a single detail layered on an otherwise schema-complete 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 purpose: it returns copyable step sequences ('which tools to call in what order, what to say') organized by job-hunting stage. This is clearly an orchestration/meta tool, distinct from execution tools like mock_interview_start. It does not explicitly differentiate itself from the similarly named sibling jobok_quickstart, which keeps it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one concrete usage hint – omit scene when the scenario is unknown to get the full list – which is genuinely useful for an optional parameter. However, it never says when to prefer this tool over jobok_quickstart or how it relates to the concrete action tools it recommends. Usage is implied rather than 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: not whether the call still works, whether it is deprecated, what it returns, or any auth/rate constraints. The only trait conveyed is that it is a legacy alias, which is identity metadata rather than behavior.

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 single short sentence is front-loaded and contains no filler, but its brevity reflects under-specification rather than disciplined conciseness — it earns little beyond the alias mapping.

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 low-complexity one-parameter compatibility alias, the description identifies the equivalent tool, which is the core need. However it omits whether the tool is deprecated, whether it should still be called, and any parameter detail, leaving meaningful gaps for an agent deciding between it and resume_score_match.

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 parameter (jdText) with 0% schema description coverage, and the description says nothing about it. The name is fairly self-explanatory, but no added meaning, format, or source guidance is supplied to compensate for the empty 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 never states a verb+resource directly; it only says this is the legacy name for resume_score_match. An agent can infer the resume-to-JD scoring purpose by proxy, but the description itself does not describe what the tool does, and it relies on the reader knowing the 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?

'旧版工具名' implies this is a deprecated/compatibility alias, which hints the agent should prefer resume_score_match, but it never explicitly says to use that tool instead or when this one is still appropriate. Usage is implied rather than 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?

With no annotations, the description carries the full burden. It discloses the computation basis (all application records) and the sections the report produces, which helps the agent understand the output shape, but it says nothing about permissions, whether it is a pure read, or behavior when there are no records.

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, front-loaded with the verb and resource, that spends its words on the actual report contents rather than filler. Slightly list-heavy but no 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 an aggregation tool with no output schema and no annotations, the description should clarify the return format and edge cases (e.g. empty application history). It names the report sections, which partially covers the output, but format and failure/empty-state behavior remain 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 (period) exists and the schema documents it at 100% coverage, including an example format ('2026年3月'). The description never mentions the period parameter or what default window applies when it is omitted, so it adds no meaning beyond the schema. 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 (生成复盘报告) plus the resource (求职复盘 based on 全部投递记录) and enumerates the report contents: funnel conversion, insights, diagnosis, and next-stage goals. The scope (over the full application history) distinguishes it from narrower aggregation siblings like application_stats, though no sibling is named 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 when-to-use guidance and no comparison to adjacent tools such as application_stats or interview_review. An agent must infer from the name alone whether this is the overall retrospective vs the per-interview review or a basic stats dump.

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?

With no annotations provided, the description carries the full burden. It usefully discloses a side effect ('并保存到本地', saves locally) and enumerates the output sections (weekly plan, projects, acceptance). However, it omits whether saving is mandatory, overwrite/overwrite-risk behavior, and size/latency expectations for a generation 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, front-loaded sentence that packs the input basis, the configurable dimension, the output contents, and the save side effect without filler. Efficient, though it omits any second sentence that could have covered usage routing.

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 generation tool with no annotations and no output schema, the description adequately covers inputs and output sections, so an agent knows what it will receive. It still lacks any explicit relationship/sequencing guidance relative to gap_analysis and no destructive/overwrite behavior detail.

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%, so the schema already documents all five parameters. The description adds only a partial echo of that (specifying week count), so the baseline of 3 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 states a specific verb and resource (生成...学习路线, generate a learning path) and details the output content (逐周计划、实战项目、验收机制). It is clearly distinct from siblings like gap_analysis or resume_rewrite, though it never explicitly names the sibling it consumes (gap_analysis) within the description text.

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 '基于短板清单' (based on a gap list) and the schema note that gaps can come from gap_analysis. There is no explicit when-to-use vs. when-not-to-use guidance or named alternatives, leaving the routing inference to the agent.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the side effect (saves to the session) and the return shape (an interviewer instruction of comment + score + follow-up), but says nothing about auth, preconditions, or failure behavior for this write 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?

A single front-loaded sentence that moves from the action to the persistence side effect to the returned value, with no filler. Slightly dense but every clause earns its place.

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 compensates by explaining the returned interviewer instruction (comment + score + follow-up), which is the key detail an agent needs. Reasonably complete for a 5-param session-recording tool, though workflow prerequisites remain 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 description coverage is 80%, so the schema already documents most parameters. The description adds no syntax, format, or meaning beyond what the schema fields provide, making the baseline 3 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?

States a specific verb (记录/保存) and resource (候选人某题的问答), plus the return payload (点评+打分+追问). It is clearly distinguishable from siblings like mock_interview_start/end and interview_review, though it never names them 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?

'用于继续推进模拟面试' implies the mid-session recording context, but there is no explicit when-to-use vs. mock_interview_end/interview_review, and no stated preconditions such as requiring an active sessionId from mock_interview_start.

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?

With no annotations, the description carries the full burden. It discloses the summarizing and report-prompt generation behavior, but omits critical terminal-operation details: whether the session is closed/deleted or merely finalized, whether it is reversible, whether an in-progress session is required, and any permission prerequisites.

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 led by the action verb, with no filler. It is efficiently sized for the tool, though it could have spent one more clause on state/reversibility instead of stopping short.

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 no annotations, so the description should do more. It hints at a generated 'report prompt' (useful, since no output schema exists) but leaves the session-state outcome and prerequisites undefined, an important gap for a terminal mutation 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 coverage is 0%, so the description must compensate, but with only one obvious parameter (sessionId) there is little to clarify. '指定...会话' loosely points at sessionId but adds no format, id-scheme, or validity information beyond the schema's type declaration.

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 (结束/end), a specific resource (指定模拟面试会话/the specified mock interview session), and the resulting side effects (summarize all Q&A and generate a deep review report prompt). This clearly separates it from siblings like mock_interview_start and mock_interview_answer, 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?

There is no explicit when-to-use/when-not-to-use guidance nor any named alternative. The only signal is the implicit interview lifecycle (start → answer → end), which the agent must infer from the name rather than the description.

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?

With no annotations, the description carries the full burden. It discloses that each entry includes progress and status, but says nothing about ordering, pagination, scope (are sessions filtered to the current user?), or whether it is a safe read-only operation. That is a meaningful gap for a tool with zero annotation coverage.

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 verb and resource lead immediately. It is efficient, though arguably too terse to carry the return-value information the missing output schema would otherwise provide.

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?

Complexity is low (no params, no nesting), and the description partially covers return content by naming progress and status. However, with no output schema and no annotations, it omits ordering, pagination, and scope, which an agent would need to interpret the result set 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 schema coverage is 100%, so there is nothing for the description to document. Baseline 4 applies since parameter semantics are trivially satisfied.

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 (历史模拟面试会话) plus the contents it surfaces (进度与状态). This clearly separates it from the action siblings (mock_interview_start / answer / end) and is unambiguous, though it does not explicitly name a contrasting 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 description gives no when-to-use guidance, no prerequisites, and no mention of alternatives. It never explains how this differs from interview_review or when a listing is preferred over fetching a single review, leaving the agent to infer usage entirely.

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?

With no annotations, the description carries the full burden. It usefully discloses that a session is created and that sessionId and opening instructions are returned, which helps the agent chain the next call. But it omits whether this consumes an LLM/paid call, whether permissions or existing profile/resume data are required, and what happens on repeated invocation (multiple concurrent 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?

Three short, front-loaded sentences: purpose first, then return values, then the workflow. Every sentence earns its place with no filler or 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?

With no output schema, the description helpfully notes the returned sessionId and opening instructions, and it lays out the full session lifecycle with its siblings. The main gap is the undocumented company/jobTitle parameters, which leaves the input side incomplete for a tool that generates an LLM-driven interview session.

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 only 33% – jdText is documented ('目标岗位 JD') but company and jobTitle have no descriptions anywhere. The description mentions no parameters at all, so it does not compensate for the coverage gap. An agent gets no guidance on what company/jobTitle should contain or whether they are optional context.

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+resource: '创建一个模拟面试会话' (create a mock interview session) plus what it returns. It clearly positions itself as the entry point of the mock_interview workflow, distinguishing it from mock_interview_answer and mock_interview_end. It stops short of distinguishing from adjacent creation tools like generate_interview_question or interview_question_bank.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names the two follow-on tools (mock_interview_answer for recording each round, mock_interview_end for finishing and reviewing), which is strong sequencing guidance. However, it doesn't state the condition under which an agent should start a mock interview at all versus using the question bank or other interview tools.

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?

No annotations are supplied, so the description carries the full disclosure burden. It conveys only that the read targets the 'currently saved' profile; it says nothing about behavior when no profile has been saved, permissions, or what form the data takes. Minimal for a getter with zero annotation coverage.

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 no filler, and the resource being read leads the statement. Nothing is padded, though it is arguably so terse that it forgoes the chance to add any of the missing context.

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 annotations, the description is the only source of information, and it does not describe what the returned profile contains or how it differs from resume data. For a simple no-argument getter this is borderline adequate, but the agent gets no picture of the response.

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 no parameters, so there are no semantics to document — baseline 4 applies. Schema coverage is 100% and the description correctly implies no input is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (读取) and resource (求职者画像), and '当前保存的' scopes it to the persisted profile rather than any transient state. It implicitly distinguishes itself from the sibling profile_save, though it never names it.

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 versus alternatives such as profile_save, resume_get, or resume_load, and no mention of prerequisites (e.g. whether a profile must already exist). For a zero-parameter getter the usage is somewhat inferable, but the description gives no explicit guidance.

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?

No annotations are provided, so the description carries the full disclosure burden. It adds meaningful cross-tool behavioral context (the profile is consumed by all other tools), but it does not state whether fields merge or replace on update, what happens to omitted fields, or whether an existing profile is required.

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 sentences, front-loaded with the action and followed by the foundational-usage note; no filler. Could be marginally tighter but every clause earns its place.

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 7-param mutation tool with no annotations and no output schema, the description covers purpose, field inventory, and cross-tool role adequately but omits update/merge semantics and whether anything is required. Enough to call safely, not enough to predict mutation behavior.

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 low at 43% (only notes/years/domain are described), so the description must compensate. It enumerates semantic labels for 目标方向(domain), 年限(years), 目标岗位(targetRoles), 意向城市(cities), 技能(skills) and 补充说明(notes), adding real meaning for the undocumented array params.

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?

Names a specific verb+resource (保存/更新求职者个人画像) and enumerates the fields it holds, so an agent can distinguish it from the sibling profile_get. It doesn't explicitly name profile_get as its read counterpart, but the save/get split is inferable.

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?

States that the profile is referenced by all other tools and recommends setting it up first, which is genuine when-to-use guidance for a foundational tool. It stops short of stating exclusions or an explicit alternative, but there is no real competing save tool.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the source-of-content behavior (current active resume, or a resume body you pass in), which is useful workflow context after resume_rewrite. However, it says nothing about whether an existing file at outputPath is overwritten, whether directories are created, what is returned (no output schema), or error conditions for a file-writing 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?

A single compact sentence that front-loads the action and resource, then lists the concrete purposes. Nothing is wasted and no filler precedes the key 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, no-annotation, no-output-schema tool, the description covers purpose and content sourcing but omits file-write semantics (overwrite behavior, failure modes, return value). Adequate as a minimum-viable definition, but not complete for a mutation that touches the user's filesystem.

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%, so all three parameters (format enum, content, outputPath) are already documented in the schema, including the default path and default format. The description only restates the content-source fallback, adding no syntax or format detail beyond the schema — 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 (导出/export) and resource (简历/resume) plus the destination (本地文件), so the agent knows exactly what the tool produces. It does not, however, differentiate itself from the sibling data_export, which an agent could plausibly confuse it with.

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 便于保存、作为附件投递或继续编辑 gives downstream use cases, which implies when the tool is relevant, but there is no explicit when-to-use vs when-not guidance and no mention of the alternative data_export. Usage must be inferred.

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?

No annotations are provided, so the description carries the full behavioral burden. '查看' implies a read, but the description says nothing about what happens if no resume is loaded, whether the result is cached/live, or the return shape beyond '内容与元信息'.

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. It is efficient, though its brevity borders on under-specification rather than true economy.

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-optional-parameter read tool with no output schema the bar is low, but the description omits error/no-resume behavior and any tie-in to the load/export siblings, leaving it only minimally viable.

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%, so the single 'preview' parameter is already fully documented in the schema. The description adds nothing about it, 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 (查看/view) and resource (当前已加载的简历) plus the content scope (内容与元信息), so an agent can tell it reads an already-loaded resume. It is missing explicit differentiation from siblings like resume_load and profile_get, which prevents a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this instead of resume_load (loading a file) or profile_get (saved profile). The '当前已加载' phrasing implies usage but the description never spells out a condition or an 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?

With no annotations, the description carries the full burden, and it does disclose real behavioral traits: the resume becomes the current active resume (a state mutation), files are auto-parsed for four formats, and skill keywords are auto-extracted afterward. It omits what happens to a previously active resume (overwrite?), error behavior on unparsable files, and any permission requirements, leaving gaps.

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-loads the purpose and outcome, then enumerates the two input modes in a single compact, well-structured sentence. 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 no output schema and no annotations, the description covers both parameters, the resulting state change, and post-load processing well enough to invoke the tool correctly. Missing edge-case behavior (overwrite of existing active resume, failure modes) keeps it from 5.

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%, so both parameters are already documented, and the filePath schema entry even lists the same supported extensions. The description adds only the 'absolute path' qualifier and the either/or relationship, 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 (加载/load) and resource (简历/resume), and adds the consequential outcome '保存为当前活跃简历' which distinguishes it from a read-only sibling like resume_get. It does not explicitly name any sibling, so it falls short of the top score.

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?

Clearly explains the two mutually exclusive invocation modes — pass an absolute filePath to have the tool parse the file, or pass raw text via content — which is exactly the routing decision an agent must make. There is no guidance on when NOT to use this tool or which sibling to prefer for other resume operations, so it stops at 4.

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?

With no annotations, the description carries the full burden. It discloses the transformation method and the output shape (对照表 + optimized resume), suggesting a generation/return rather than an in-place save, which is useful. However it never states whether the stored resume is modified, permission needs, or invocation cost, so key behavioral traits remain unstated.

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, front-loaded with the core action and JD basis, and it closes with the outputs. No padding. Minor deduction only because cramming method and deliverable into one clause slightly reduces scannability.

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 no annotations, so the description must stand in for both. It does describe the two expected artifacts, but leaves open whether the resume is persisted/mutated and how extraFocus affects the result, which an agent needs given the many adjacent resume/profile write 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 coverage is 50% (only extraFocus is documented). The description's '基于 JD' implies jdText is the source JD, adding mild meaning, but it says nothing about extraFocus semantics (e.g., how it steers the rewrite) or format expectations for jdText.

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 (改写/rewrite) and resource (简历), plus the method (基于 JD, STAR, 量化成果, ATS 关键词) and the two deliverables (对照表 + 完整优化简历). Clear and specific, but it never differentiates itself from close siblings like ats_optimize or resume_score_match, whose turf (ATS keywords, JD matching) it visibly overlaps.

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: the description says rewriting is driven by a JD, so an agent can infer you invoke it when tailoring a resume to a posting. There is no explicit when-to-use/when-not, no prerequisites, and no routing away from the overlapping ats_optimize sibling.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the output categories and that it uses the current resume, but never states whether the operation is read-only, whether it persists anything, or any auth/rate limits.

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 front-loaded sentence that names the action, inputs, and outputs without filler. Every clause earns its place.

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 scoring tool with no output schema, the description adequately covers purpose and return categories. It is less complete on usage routing and safety behavior, but the low complexity limits the 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 coverage is 100% for the single jdText parameter, so the schema already documents it. The description adds no parameter syntax or format details beyond what the schema provides, making the baseline 3 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?

States a specific verb (匹配度打分) and resources (当前简历 vs 目标 JD), plus enumerated outputs. It does not explicitly differentiate from the similar sibling job_score_match, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use, prerequisites, or alternatives are given. The description implies the scenario but does not route the agent between this and job_score_match, gap_analysis, or ats_optimize.

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?

No annotations are provided, so the description carries the full burden. '按 id 删除' implies a destructive mutation, yet nothing is said about irreversibility, whether confirmation is needed, permission requirements, or what happens if the id is invalid. For a delete tool with zero annotation coverage this is a meaningful 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?

Two very short sentences with the action front-loaded and the id source immediately after. Nothing is wasted, though it is brief enough that it omits context rather than being an exemplary compact definition.

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?

A one-parameter destructive tool needs little param guidance and no output schema, and the id source is covered. However, with no annotations and no statement of consequence or reversibility for a delete operation, the safety-relevant context is incomplete.

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% and the schema already documents the id parameter with an example format. The description adds only the practical pointer that the id comes from strength_list; it does not extend the parameter's meaning 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 (已沉淀的优势) plus the keying mechanism (按 id), which cleanly separates it from strength_save, strength_list and strength_mine. It is clear but does not explicitly contrast itself against those siblings, so it stops short of full 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?

The description points to strength_list as the way to obtain the id, which is a useful routing hint, but it gives no conditions for when deletion is appropriate versus other actions and no caveats. Usage is implied rather than 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?

With no annotations at all, the description carries the full behavioral burden. It does disclose what is returned (the four-step chain and a completeness statistic), which is genuinely useful, but it never states that the operation is read-only, nor does it mention ordering, pagination, or permissions.

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 verb and resource first and the output shape second. No filler, no repetition of the name or title.

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 tool with no output schema and no annotations, the description is adequate because it sketches the return content. It still omits the read-only guarantee and any caveats about result volume, which matter when nothing else documents the tool's behavior.

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 disambiguate and no schema-level documentation is needed. The baseline for a parameterless tool is 4.

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 resource (已沉淀的个人优势), and even previews the returned structure (完整的四步链条与链条完整度统计). It is clearly a read/list operation, but it never names or contrasts itself with the close siblings strength_mine, strength_save, or strength_delete.

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 qualifier 已沉淀 (already accumulated/saved) implicitly tells the agent this reads stored strengths rather than mining new ones, which is the key distinction from strength_mine. However, there is no explicit when-to-use, when-not-to-use, or 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?

With no annotations, the description carries the burden and discloses substantial behavior: the forced four-step chain (证据→行为→能力→岗位信号), the tags applied to each strength, and a hard constraint forbidding personality labels. It stops short of saying whether results are persisted or what the return payload looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight clauses, purpose front-loaded, with the processing constraint immediately following. Dense but every element (sources, chain, tagging, prohibition) carries information; no filler sentences.

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-param, zero-required tool with no output schema, the description covers the method and the shape of each produced strength. The remaining gap is clarifying the return format and whether the mined strengths are persisted or only returned for a later strength_save call.

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 all three params are already documented in the schema. The description reinforces the input sources (resume + supplementary materials) and the role-signal translation, but adds no syntax or format 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 (个人优势) sourced from resume plus supplementary materials. It is immediately distinguishable from siblings like strength_save, strength_list, or strength_delete, which operate on already-produced strengths.

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 frames the activity but never states when to use this tool versus alternatives (e.g. save the mined result via strength_save, or run before/after resume_score_match). Usage is implied by the workflow rather than explicitly routed.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses three rejection conditions and that failures come with an explanation, but says nothing about persistence semantics: duplicate titles, overwrite vs append behavior, or what a successful save returns.

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, purpose front-loaded, constraint second. No filler, no restatement of the tool name, and the enforcement rules are packed into a single readable clause.

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 11-parameter write tool with full schema descriptions and no output schema, the description covers the core chain and failure modes adequately. The gap is success-side semantics (duplicate handling, what is persisted) and no mention of the optional targetRoles/missingProof/elevatorPitch fields, though the schema documents those.

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 baseline is 3, but the description adds real meaning by framing evidence → behavior → ability → jobSignal as a mandatory ordered chain and defining what makes evidence unacceptable ('过于空泛') or a title invalid (personality label). That goes beyond the per-field schema text.

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: saving one strength ('保存一条已挖掘的优势'), and the word '已挖掘' hints that it consumes output from strength_mine rather than producing it. It never names the sibling explicitly, so the differentiation from strength_mine/strength_list/strength_delete is left partly to inference.

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 the strength must already exist before saving and enumerates the conditions under which the write will be refused (incomplete chain, vague evidence, personality label as strength). However, it never states the upstream step ('run strength_mine first') or names any alternative sibling, so the when-to-use routing is only implied.

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