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

No annotations are provided, so the description carries the transparency burden. It discloses the key behavioral constraint (不编造量化指标 - does not fabricate quantitative metrics), which is valuable honesty about what the tool will NOT do. However, it doesn't disclose output structure, error behavior, or what happens when repo_info is incomplete, leaving some gaps for a tool with no annotation support.

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 reasonably succinct with a clear header line followed by a brief 'when to call' section. The structure with the explicit 什么时候该调用 (when to call) header makes the pipeline context scannable. Minor waste exists in restating thresholds in the usage section, but overall it's efficient and front-loaded with the core purpose.

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 an output schema present and a well-defined pipeline position, the description covers the key decision context. It explains the github_username contribution logic, the ordering relative to siblings, and the honesty constraint. It's not exhaustive (doesn't explain repo_info handling or fallbacks), but given the output schema exists and the tool has a clear niche in a documented workflow, it's adequately complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the github_username parameter's role (judging contribution_level with thresholds) but doesn't describe repo_info or target_role beyond what the schema trivially shows. The contribution_level thresholds (primary ≥50% / contributor 20–50% / minor <20%) are genuinely useful semantics not in the schema, though two of three params remain unexplained.

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 ('从仓库客观数据提炼可用于简历的技术要点' - extract resume technical points from repo data) with a clear constraint (不编造量化指标 - don't fabricate metrics). It distinguishes somewhat from siblings by its position in the pipeline (between fetch_repo_info and generate_bullet_points), though it doesn't deeply contrast with generate_bullet_points which could overlap in 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?

The description explicitly states when to call it ('fetch_repo_info 成功之后、generate_bullet_points 之前' - after fetch_repo_info succeeds, before generate_bullet_points). It also explains usage of the github_username parameter to determine contribution level, providing clear pipeline ordering guidance that differentiates it from 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?

No annotations are provided, so the description carries the full burden. It discloses the output is a human-readable change summary at the project granularity, and lists covered areas. However, it doesn't clarify whether this is a read-only operation (it reads two data objects), what happens with invalid/mismatched data structures, or performance implications. Given no annotation coverage, this is acceptable 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?

The description is compact and well-structured with clear headers ('什么时候该调用' and '覆盖'). Every line earns its place: the purpose, the usage timing, and the coverage scope. Could be slightly more concise by removing the literal backslash escapes in the code formatting, but it's efficient overall.

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

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

The tool has 2 parameters with 0% schema description coverage, has nested objects, and an output schema exists. Given the complexity and that an output schema handles return values, the description adequately covers purpose, timing, and coverage scope. The only minor gap is not specifying the exact data shape expected for old/new beyond 'ResumeData' context, but since the output schema documents returns, overall completeness is solid.

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. The description implies 'old' and 'new' are ResumeData objects by context (the tool diffs resume versions), even though the schema only types them as generic objects with additionalProperties:true. The description doesn't document parameter format or constraints beyond what's inferred, so it meets the baseline but doesn't excel given the 0% 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 clearly states the verb ('diff'), the resource ('ResumeData versions'), and the specific output type ('human-readable change summary, project-level, like git diff'). It distinguishes itself from siblings by focusing on comparing old vs new resume versions, which is distinct from merge_into_resume and render_pdf in the sibling list.

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?

Explicitly states WHEN to use it: 'after merge_into_resume, before render_pdf, to let the user confirm changes.' This direct call-stack positioning names the specific siblings it relates to and the temporal ordering. The coverage section further clarifies what it examines (basic info, projects, work/education counts, skill group changes).

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 does disclose what the tool fetches and that output is a RepoInfo object. However, it doesn't disclose behavioral details like API rate-limiting implications, network dependency/failure modes, or how much data it returns. For a network-fetching tool with zero annotation coverage, more disclosure about potential failure or cost would be valuable.

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

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

Well-structured and compact. The description uses a clear header ('什么时候该调用') to separate the what from the when. Every sentence earns its place: the first sentence lists the fetched data, the section explains invocation timing and output flow. No 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?

The tool has an output schema (RepoInfo), which reduces the need to explain return values. With only 2 parameters and a clear downstream consumer (analyze_repo_for_resume) plus conditional github_username behavior, the description covers the essential use cases well. Minor gap: doesn't mention failure handling when the repo doesn't exist or is private, but this is acceptable given the output schema and clear purpose.

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 explains github_username's purpose ('以便 contributor_stats 直接带上该用户的占比' - so contributor_stats can directly include that user's percentage), adding meaning the bare 'Github Username' schema title lacks. repo_url is implicitly clear given the description's framing. However, it doesn't enumerate that repo_url could also accept owner/repo shorthand in the parameter details, though the usage section mentions this.

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 set ('抓取仓库元数据、README、语言占比、近期 commit、依赖文件与贡献者统计' - fetch repo metadata, README, language stats, recent commits, dependency files, and contributor stats). It clearly distinguishes what data is gathered but doesn't explicitly contrast with siblings; however, the sibling tools (parse_resume, analyze_repo_for_resume, generate_bullet_points) are clearly downstream resume-processing steps, so the data-fetching purpose is well differentiated in context.

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 '什么时候该调用' section explicitly states when to use it: after the user provides a GitHub repo URL (or owner/repo). It also states the output feeds into analyze_repo_for_resume, providing clear downstream context. It even gives conditional guidance on passing github_username for contributor_stats. This is explicit when-to-use guidance with integration 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. The description discloses behavioral rules (empty bullets with skip_project_entry=true for negligible contributions, prohibition on certain verbs), which is useful behavioral context. However, it doesn't disclose the return format beyond mentioning bullets and skip_project_entry, and an output schema exists which presumably documents the return structure. Decent but not exhaustive behavioral disclosure.

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

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

The description is compact and front-loaded with the essential purpose in the opening sentence. The usage section is well-structured with clear headers and bullet points. Every sentence earns its place with actionable information, 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?

The tool sits in a complex multi-step pipeline with rich input (nested analysis object) and an output schema. The description covers the pipeline position, the decision logic for verb selection, and edge cases (negligible contributions). Given the output schema exists and handles return-value documentation, the description is reasonably complete. Minor gaps: no guidance on style_reference behavior or how resume_style affects output.

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

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

Schema description coverage is 0%, so the description carries the compensation burden. The description explains the 'analysis' parameter's internal fields (contribution_level, absolute_contribution_signal), which adds real meaning. However, resume_style and style_reference are entirely undocumented—resume_style has a default 'concise' but no explanation of options, and style_reference's purpose is unspecified. Partial compensation for a 3-param 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 states a specific verb+resource: 'generate 2-3 resume-style bullet points based on analysis results'. It distinguishes from siblings by referencing the pipeline position (after analyze_repo_for_resume, before merge_into_resume), though the core purpose itself is clear enough that sibling differentiation is somewhat light on the actual generation semantics.

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?

Excellent explicit guidance: states exactly when to call (after analyze_repo_for_resume succeeds, before merge_into_resume), and provides a decision tree on verb intensity based on analysis.contribution_level, with specific breakdowns for minor contributions (negligible/modest/substantial) and explicit prohibitions ('still forbidden to use 主导/独立完成'). This is exemplary 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?

There are no annotations provided, so the description carries the full behavioral burden. It discloses key mutation behaviors: default insertion at position 0, the error_code=project_already_exists behavior instead of silent duplicate insertion, and replacement semantics with re-positioning when overwrite=true. This is meaningful behavioral context beyond the schema.

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

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

Well-organized with clear section headers ('when to call', 'behavior'), concise bullet points, and zero filler. Every sentence adds functional information. The structure makes scanning and comprehension efficient.

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 tool with 8 parameters, nested objects, and an output schema, the description covers the critical behavioral paths (insert, overwrite, dedup) and pipeline placement well. Since an output schema exists, return value documentation isn't required from the description. The only minor gap is no guidance on how resume_data/new_bullets specifically interact, though these are reasonably inferable.

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 explains position (defaults to 0, front of list), overwrite semantics, and project_name dedup logic — adding meaning to at least 3 key parameters that influence behavior. It doesn't cover role/tech_stack/project_url/new_bullets explicitly, but these are intuitively self-describing from 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 states a specific action ('insert new project experience into resume's projects list'), names the resource (resume projects), and specifies the mechanism (supports position and overwrite). It also implicitly distinguishes from siblings — diff_resume_versions and render_pdf are clearly the pre/post steps, establishing this tool's unique role in the pipeline.

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 'when to call' section explicitly places this tool between generation (generate_bullet_points/analyze) and output (diff_resume_versions/render_pdf), giving clear pipeline context. It doesn't explicitly mention when NOT to use it versus an alternative, but the timing guidance is strong enough to orient 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 burden. It does disclose success/failure return structures clearly, which is useful. However, it doesn't describe edge cases (invalid PDFs, encrypted files, multilingual text), error scenarios beyond error_code/message/details, or whether the tool is purely local/stateless. Some behavioral transparency is present but not comprehensive.

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 well-structured with headings (什么时候该调用/参数/返回) and front-loads the core purpose. The success/failure return format examples are clearly valuable. Minor redundancy: the return section formatting is somewhat verbose for what could be a compact statement, but overall the structure is efficient and scannable.

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

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

An output schema exists (the ResumeData structure), so return-value explanation isn't strictly required, though the description does give a helpful failure schema. The tool has only 1 parameter, reducing complexity burden. The description adequately covers workflow position, parameter semantics, and return format — reasonable completeness given the tool's modest complexity, though error-message details are absent.

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

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

With schema description coverage at 0%, the description must compensate, and it does explain the single pdf_path parameter as '本地 PDF 的绝对或相对路径'. This adds the absolute-or-relative distinction not in the schema. However, it doesn't clarify constraints like file extension requirements or disk-access permissions, leaving the description only marginally more informative than the schema's bare 'Pdf Path' title.

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+resource ('解析本地 PDF 简历为结构化 JSON') and enumerates the output fields (姓名/联系方式/教育/工作/项目/技能). It clearly distinguishes from sibling tools by being the designated first-step parsing tool, while siblings handle repo analysis, merging, and rendering.

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 explicitly states WHEN to use it ('工作流的第一步') and the dependency relationship ('后续的 merge / render 都依赖这里产出的 ResumeData'), making the workflow position and alternatives clear. It specifies the trigger condition of receiving the PDF path.

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 discloses several behavioral traits: Chinese font stack details, default write location (managed temp dir with TTL cleanup) vs explicit output_path (not auto-deleted), and the Windows GTK/Pango/Cairo dependency with a render_failed error. This is strong disclosure, though it doesn't describe output structure/return format beyond the path.

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 well-structured with clear section headers (When to call, Template, Notes) and front-loaded purpose. It's moderately long but every section earns its place — behavioral notes, error codes, and template variants are all meaningful. A slight trim could tighten it but organization is strong.

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

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

The tool has 3 parameters with 0% schema coverage, nested objects, an output schema, and no annotations. The description compensates well by covering template options, output path semantics, dependencies, fonts, and error codes. It could be stronger on resume_data shape expectations, but it otherwise provides a complete picture for this workflow-final tool.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains the template parameter's options (modern default, compact, unknown → template_not_found) and the output_path lifetime semantics (managed temp vs explicit). However, it doesn't detail the resume_data structure/expected shape, relying on the generic object schema. Given 0% coverage, this is solid compensation, just missing resume_data specifics.

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+resource — Jinja2 HTML template + WeasyPrint to render a structured resume into PDF and return the absolute file path. It explicitly mentions the template options and error behaviors, and its role as the final workflow step clearly distinguishes it from siblings like parse_resume, generate_bullet_points, and merge_into_resume.

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 'When to call' section explicitly states to invoke this after the user confirms the merge result (optionally via diff_resume_versions), as the final step of the workflow. It also clarifies template selection behavior and error codes, giving clear when-to-use guidance against the sibling pipeline tools.

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