Liepin Jobs

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an 'add' operation (implying creation/mutation) but doesn't disclose authentication requirements, rate limits, whether this creates a new record vs. appending to existing ones, or what happens on success/failure. The description adds minimal behavioral context beyond the obvious 'add' implication.

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

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

The description is extremely concise with just two Chinese phrases totaling 9 characters. It's front-loaded with the core purpose and includes one qualifying constraint. Every element serves a purpose with zero wasted words 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?

For a mutation tool with 7 parameters and no annotations or output schema, the description is insufficiently complete. It doesn't explain the mutation's scope (creates new vs. modifies existing), authentication needs, error conditions, or return values. While the schema provides excellent parameter documentation, the description fails to address broader behavioral and contextual aspects needed for safe tool invocation.

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

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

Schema description coverage is 100%, providing detailed documentation for all 7 parameters including formats, allowed values, and optional/required status. The description adds '专业必填' (major is required) which slightly clarifies the schema's '高中及以下可不填' (for high school and below, may not fill), but overall adds minimal semantic value beyond what's already comprehensively covered in the 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 clearly states the action ('添加教育经历' - add educational experience) and specifies the resource (education experience). It distinguishes from siblings by focusing specifically on education rather than work or projects, but doesn't explicitly differentiate from 'modify-edu-exp' which handles modifications of the same resource.

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 provides minimal usage guidance with '高中和初中以上，专业必填' (for high school and above, major is required), which gives some context about educational level requirements. However, it doesn't explain when to use this vs. 'modify-edu-exp' for updates, nor does it mention any prerequisites or alternatives among the sibling 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?

With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It implies a write operation ('添加' means add), but doesn't specify whether this creates a new record, requires permissions, has side effects (e.g., updating a user profile), or returns any confirmation. For a mutation tool with zero annotation coverage, this is inadequate.

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

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

The description is extremely concise with just three Chinese characters ('添加求职期望'), which is front-loaded and wastes no words. While it's under-specified for completeness, it earns full marks for brevity and structure within this dimension.

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

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

Given the complexity (10 parameters, mutation operation, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's role in context (e.g., resume management), behavioral traits like authentication needs, or what happens upon success/failure. For a tool with significant input complexity, this minimal description is insufficient.

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%, with all 10 parameters clearly documented in the input schema (e.g., 'dq' as expected location, 'jobtitle' as position category). The description adds no parameter information beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.

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 '添加求职期望' (Add job want) is a tautology that essentially restates the tool name in Chinese. While it indicates the general action of adding something related to job preferences, it lacks specificity about what exactly is being added (e.g., a job preference record to a user profile) and doesn't distinguish this from sibling tools like 'modify-job-want' or 'add-work-exp'.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., user authentication), context (e.g., part of resume building), or comparisons to sibling tools like 'modify-job-want' for updates or 'add-work-exp' for different data types. This leaves the agent with no 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 of behavioral disclosure. '添加项目经历' implies a write operation that creates new data, but it doesn't specify whether this requires authentication, what happens on success (e.g., returns an ID or confirmation), potential side effects (e.g., updates a resume), error conditions, or rate limits. The description is minimal and fails to provide essential 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?

The description is extremely concise at just three Chinese characters ('添加项目经历'), which translates to 'Add project experience'. It's front-loaded with the core action and resource, with zero wasted words. While it lacks detail, it efficiently communicates the basic intent without redundancy or fluff.

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

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

Given the complexity of a mutation tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, authentication needs, or how it fits into the broader context of resume management with sibling tools. The minimal description leaves significant gaps for an AI agent to understand and invoke the tool correctly.

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

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

Schema description coverage is 100%, with all 8 parameters documented in the input schema (e.g., 'name' as project name, 'start' as start time in YYYYMM format). The description adds no parameter information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3, as the schema does the heavy lifting and the description doesn't need to compensate.

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 '添加项目经历' (Add project experience) is a tautology that essentially restates the tool name 'add-project-exp' in Chinese. It doesn't specify what resource this acts upon (e.g., a user's resume or profile), nor does it distinguish this from sibling tools like 'add-work-exp' or 'modify-project-exp'. The purpose is clear at a basic level but lacks specificity and 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a user must be logged in or have a resume created), nor does it clarify the relationship with sibling tools like 'modify-project-exp' for updates or 'add-work-exp' for different types of experience. Usage is implied only by the name, with no explicit context 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?

With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read-only or mutation operation (though 'add' implies creation), what permissions are required, potential side effects (e.g., updating a resume), error conditions, or response format. The description fails to compensate for the lack of annotations.

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

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

The description is a single phrase '添加工作经历', which is under-specified rather than concise. It lacks structure (e.g., no front-loaded key details) and fails to earn its place by providing meaningful context. While brief, it doesn't achieve effective conciseness due to insufficient content.

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

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

Given the complexity (18 parameters, 4 required), lack of annotations, and no output schema, the description is severely incomplete. It doesn't explain the tool's purpose in context, usage scenarios, behavioral traits, or return values. For a mutation tool with many parameters, this minimal description is inadequate.

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

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

The input schema has 100% description coverage, with all 18 parameters documented in Chinese (e.g., '公司名称' for compName, '职位名称' for rwTitle). The description adds no additional parameter information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3 even with no param info in the 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 '添加工作经历' (Add work experience) is a tautology that merely restates the tool name 'add-work-exp' in Chinese. It doesn't specify what 'adding' entails operationally (e.g., creating a record in a resume/profile system) or distinguish this tool from sibling tools like 'modify-work-exp' or 'add-edu-exp'. While the verb 'add' is clear, the description lacks specificity about the resource context and 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., user authentication), when to choose 'add-work-exp' over 'modify-work-exp' for existing entries, or how it relates to sibling tools like 'add-edu-exp' for education history. There's no explicit or implied context for usage decisions.

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 states this is a modification operation and that fields cannot be empty, but doesn't disclose critical behavioral traits like whether it requires authentication, what happens to unspecified fields (partial vs. full updates), error handling, or side effects. For a mutation tool with zero annotation coverage, this is insufficient.

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

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

The description is concise and front-loaded with the core purpose in the first clause. It consists of two clear sentences with no wasted words, though it could be slightly more structured (e.g., separating constraints).

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

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

Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on authentication needs, response format, error conditions, and how it differs from sibling tools. The 100% schema coverage helps with parameters, but overall context for safe and effective use is inadequate.

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 8 parameters with detailed descriptions and formats. The description adds minimal value beyond the schema by emphasizing that fields cannot be empty, but doesn't provide additional semantics like validation rules or interdependencies. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: '修改教育经历' (modify education experience). It specifies the action (modify), resource (education experience), and mechanism (by education experience ID). However, it doesn't explicitly differentiate from sibling tools like 'modify-work-exp' or 'modify-project-exp' beyond the resource type.

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 provides minimal usage guidance: it mentions that update fields cannot be empty, but doesn't specify when to use this tool versus alternatives like 'add-edu-exp' or other modify tools. No explicit context, prerequisites, or exclusions are provided.

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 states this is an update operation ('修改', '更新'), implying mutation, but lacks critical behavioral details: it doesn't specify permissions needed, whether changes are reversible, error handling for invalid IDs or fields, or what happens to unspecified fields (partial vs. full updates). The constraint '传入的更新字段不能为空' (update fields cannot be empty) adds some context but is insufficient 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?

The description is concise and front-loaded: two sentences that state the core action and a key constraint. There's no wasted text, but it could be slightly more structured (e.g., separating purpose from rules).

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 11 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral transparency (e.g., side effects, auth needs), usage guidelines vs. siblings, and details on response format or errors. The high schema coverage helps with parameters, but overall context is inadequate for safe and effective use.

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%, with all 11 parameters well-documented in the schema (e.g., '期望地点名称' for 'dq'). The description adds minimal value beyond the schema: it emphasizes the 'id' parameter is required for updates and that update fields cannot be empty, but doesn't provide additional syntax, format, or interaction details. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose: '修改求职期望' (modify job expectations) and specifies it updates fields based on job expectation ID. It distinguishes from siblings like 'add-job-want' by focusing on updates rather than creation. However, it doesn't explicitly differentiate from other modify tools (e.g., modify-edu-exp) beyond the resource type.

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 provides minimal guidance: it mentions the 'id' parameter is required for updates and that update fields cannot be empty. However, it offers no explicit when-to-use vs. alternatives (e.g., when to use this vs. add-job-want or other modify tools), no prerequisites, and no context about user roles or system state.

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 full burden. It mentions that update fields cannot be empty, which adds some behavioral context about input validation. However, it lacks details on permissions, side effects (e.g., whether changes are reversible), error handling, or response format. For a mutation tool with zero annotation coverage, this is insufficient.

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

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

The description is concise with two sentences, front-loading the core action ('修改项目经历') and adding a constraint. There is no wasted text, though it could be slightly more structured (e.g., separating purpose from rules).

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

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

Given a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., auth needs, side effects), usage context, and return values. While the schema covers parameters well, the overall context for safe and effective tool use is inadequate.

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%, with all 9 parameters well-documented in the input schema (e.g., 'id' as required project experience ID, date formats). The description adds minimal value beyond the schema, only implying that fields are updated by ID and cannot be empty. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the verb ('修改' meaning 'modify') and resource ('项目经历' meaning 'project experience'), specifying it updates fields by project experience ID. It distinguishes from siblings like 'add-project-exp' by focusing on updates rather than creation, though it doesn't explicitly compare to other modify tools like 'modify-work-exp'.

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 is provided on when to use this tool versus alternatives. While it implies usage for updating existing project experiences, it doesn't specify prerequisites (e.g., needing an existing ID), exclusions, or when to choose other modify tools (e.g., 'modify-work-exp'). The mention that '传入的更新字段不能为空' (update fields cannot be empty) is a constraint, not usage 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 burden of behavioral disclosure. It states the tool modifies/updates fields, implying a mutation operation, but doesn't disclose critical traits: whether it requires authentication, what happens to fields not provided (e.g., partial updates vs. full overwrites), if changes are reversible, potential rate limits, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence that front-loads the core action and target. There's no wasted verbiage or redundancy. However, it could be slightly more structured by explicitly mentioning it's for partial updates, but as-is, it's appropriately concise for the tool's complexity.

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

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

Given the tool's complexity (17 parameters, mutation operation, no output schema, and no annotations), the description is incomplete. It lacks information on behavioral traits (e.g., auth needs, update behavior), usage context, and output expectations. While the schema covers parameters well, the description fails to address other critical aspects needed for safe and effective use, especially for a write 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?

The schema description coverage is 100%, with each parameter well-documented in the input schema (e.g., 'sex' with allowed values, 'birthday' with format). The description adds no parameter-specific information beyond stating it updates '传入的字段数据' (incoming field data), which is already implied by the tool's purpose. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.

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

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

The description clearly states the action ('修改' meaning 'modify') and the target resource ('简历的【基本信息】数据' meaning 'resume basic information data'), which is specific and unambiguous. It distinguishes itself from siblings like 'modify-work-exp' or 'modify-edu-exp' by focusing on basic info rather than work experience or education. However, it doesn't explicitly mention that it updates only the fields provided, which could be slightly more precise.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing resume), exclusions (e.g., not for adding new sections), or compare it to sibling tools like 'my-resume' (which might retrieve resume data) or other modify tools. Usage is implied only by the tool name and description, with no explicit 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 full burden for behavioral disclosure. '修改' (modify) implies a mutation operation, but the description fails to disclose critical traits such as authentication requirements, whether changes are reversible, side effects, or error conditions. This is inadequate for a mutation 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?

The description is extremely concise with just three Chinese characters, which is efficient and front-loaded. However, it borders on under-specification rather than optimal conciseness, as it lacks necessary detail for clarity and completeness, slightly reducing its effectiveness.

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 and no output schema, the description is incomplete. It does not explain what the tool returns, error handling, or behavioral context. Given the complexity of modifying user data and the lack of structured support, the description fails to provide sufficient information for reliable agent use.

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%, with the single parameter 'selfAssess' documented in the schema as '自我评价内容' (self-assessment content). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for adequate coverage without extra value.

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 '修改自我评价' (modify self-assessment) is a tautology that restates the tool name in Chinese without adding meaningful clarification. It specifies the verb 'modify' and resource 'self-assessment' but lacks detail about what this actually does operationally or how it differs from similar tools like 'modify-resume-base-info'. The purpose is stated but remains vague and indistinguishable from 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions. Given siblings like 'modify-resume-base-info' that might handle related resume updates, the absence of usage guidelines leaves the agent without direction on appropriate tool 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It indicates this is a mutation operation ('修改' - modify) and that update fields cannot be empty, but lacks critical details: required permissions, whether changes are reversible, error handling, or what happens to unspecified fields. For a mutation tool with 19 parameters, this is insufficient.

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

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

The description is a single, efficient sentence that states the core action and key constraint. It's appropriately sized without redundancy, though it could be more front-loaded with additional context. No wasted words.

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 complex mutation tool with 19 parameters, no annotations, and no output schema, the description is inadequate. It lacks behavioral context (permissions, reversibility), usage guidance versus siblings, and output expectations. The schema covers parameters well, but the description fails to compensate for missing annotation and output information.

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%, with each parameter well-documented in the schema (e.g., 'workId: 工作经历 ID，更新时必填', 'workStart: 在职开始时间，格式 YYYYMM'). The description adds only that update fields cannot be empty, which is minimal value beyond the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the action ('修改工作经验' - modify work experience) and resource ('工作经验' - work experience), specifying it updates fields by work experience ID. It distinguishes from 'add-work-exp' (create vs update) but doesn't explicitly differentiate from other modify tools like 'modify-edu-exp' or 'modify-project-exp'.

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 provides minimal guidance: it states the tool updates work experience by ID and that update fields cannot be empty. However, it offers no guidance on when to use this versus alternatives like 'add-work-exp' (create new) or other modify tools, nor any prerequisites or constraints beyond the non-empty requirement.

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 full burden. It states the tool fetches and outputs raw resume content, which implies a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, data format, or potential errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

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

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

The description is extremely concise and front-loaded with a single clear sentence in Chinese: '获取我的简历,输出简历原始内容' (Get my resume, output resume raw content). Every word earns its place by specifying the action and resource without any fluff 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?

Given the tool's simplicity (0 params, no output schema, no annotations), the description is minimal but adequate for basic understanding. However, it lacks completeness for practical use: no output format details (e.g., JSON, text), no error handling info, and no context on data scope (e.g., which resume if multiple exist). With no annotations or output schema, the description should compensate more.

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

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

The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter details, so it meets the baseline for no parameters. It efficiently focuses on the tool's action without unnecessary param explanations.

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

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

The description clearly states the tool's purpose with specific verbs ('获取' meaning 'get/fetch' and '输出' meaning 'output') and resource ('我的简历' meaning 'my resume'). It distinguishes from siblings by focusing on retrieval rather than modification or job-related actions. However, it doesn't explicitly contrast with potential similar retrieval tools (though none exist in 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 description's focus on retrieving 'my resume' content, suggesting it should be used when the raw resume data is needed. However, there's no explicit guidance on when to use this versus alternatives (like viewing formatted versions if they existed) or any prerequisites. The context helps since siblings are all modification/job tools, but no explicit comparison is provided.

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 full burden for behavioral disclosure. It only states what parameters the tool accepts, not how it behaves: no information about pagination, rate limits, authentication requirements, error conditions, or what the returned job list looks like. For a search tool with 9 parameters, this leaves significant behavioral 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?

The description is a single, efficient sentence that lists all search parameters. It's appropriately front-loaded with the core purpose ('获取匹配的职位列表') followed by parameter enumeration. No wasted words, though it could be slightly more structured for readability.

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 search tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the returned job list contains, how results are ordered, whether all parameters are optional, or any search behavior details. The agent would have significant gaps in understanding how to effectively use this tool.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description lists the parameters but adds no additional semantic context beyond what's in the schema properties. This meets the baseline of 3 when schema coverage is complete, but doesn't provide extra value like parameter interactions or search logic.

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

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

The description clearly states the tool's purpose: '获取匹配的职位列表' (get matching job listings) with specific filtering criteria. It distinguishes itself from siblings like 'user-search-job' by focusing on comprehensive job search with multiple parameters rather than user-specific job operations. However, it doesn't explicitly contrast with 'user-search-job' in the description text itself.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'user-search-job' or explain the difference between general job search and user-specific job search. There's no indication of prerequisites, limitations, or appropriate contexts for using this 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?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action ('应聘职位') which implies a write/mutation operation, but doesn't disclose authentication needs, rate limits, confirmation requirements, or what happens upon success/failure. The description is functional but lacks critical operational 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?

The description is a single, efficient Chinese sentence that directly states the tool's purpose and required inputs. Every word earns its place with zero redundancy or unnecessary elaboration. It's appropriately sized for this simple two-parameter tool.

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 and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, side effects, or authentication requirements. While concise, it lacks the contextual depth needed for an agent to use this tool confidently in a real application scenario.

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%, with both parameters ('jobId', 'jobKind') documented in the schema. The description mentions these parameters but adds no additional semantic context beyond what's in the schema (e.g., valid jobKind values, jobId format/source, or relationship between them). Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the action ('应聘职位' - apply for job) and specifies the required inputs ('指定职位id和职位类型' - specify job ID and job type). It distinguishes from siblings like 'search-jobs' (search) and 'modify-resume-base-info' (modify resume), but doesn't explicitly contrast with other application-related tools if they exist.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a completed resume), what happens after application, or when to choose this over other job-related tools like 'search-jobs' or 'my-resume'. Usage context is implied but not stated.

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

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

With no annotations, the description carries full burden but provides minimal behavioral context. It mentions retrieving a list but doesn't disclose pagination behavior (implied by 'page' parameter), rate limits, authentication needs, or what happens when no parameters are provided. This is inadequate for a search tool with 10 parameters.

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

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

The description is a single, efficient sentence that lists all parameters without unnecessary elaboration. It's appropriately front-loaded with the core purpose, though it could be slightly more structured for readability.

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 search tool with 10 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral details (e.g., pagination, defaults, error handling), usage context, and output format explanation, leaving significant gaps for the agent.

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

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

Schema description coverage is 100%, so the schema fully documents all 10 parameters. The description lists parameter names in Chinese but adds no additional meaning, syntax, or format details beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: '获取匹配的职位列表' (get matching job listings) with specific filtering criteria. It distinguishes itself from siblings like 'search-jobs' by focusing on user-specific job search parameters, though the distinction could be more 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?

No guidance is provided on when to use this tool versus alternatives like 'search-jobs'. The description lists parameters but doesn't explain context, prerequisites, or comparison with sibling tools, leaving the agent to infer usage scenarios.

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