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

With no annotations, the description carries the full burden and does well: it discloses that this is a container-level copy with hand-built ADTS headers, that no transcoding/resampling occurs, and that no external binary is required. It omits failure behavior when the source has no AAC track and says nothing about output overwrite semantics.

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 dense sentences, front-loaded with the operation and format, followed by the hard constraint. Nothing is padding; the parenthetical sample-table detail earns its place by explaining how the extraction works and why the result is playable.

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 two-parameter, no-output-schema tool this covers the essentials: input formats, output artifact, and the no-WAV limitation that would otherwise cause a wrong call. A note on the no-AAC-track case or the returned location would make it fully self-sufficient.

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

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

Schema coverage is 100% — both input_path and output_path are documented in the schema, including the same-directory default. The description adds no additional meaning about these parameters, so the baseline of 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 (extract) and resource (AAC audio track from mp4/m4a), names the output format (.aac ADTS raw stream) and the mechanism (sample-table stsz/stco/stsc direct extraction). An agent can distinguish this from every sibling tool, none of which touches audio streams, without opening the schema.

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

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

Makes the use case explicit — the resulting .aac can be played directly or fed to speech recognition — and fences off an expectation an agent might otherwise have by noting there is no ffmpeg, so no resampling or WAV conversion. It stops short of naming an alternative tool for the WAV case or stating preconditions such as the source actually needing an AAC track.

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 disclosure burden and does well: it explains the two-phase algorithm (size bucketing first, hashing only same-size candidates), states the return payload (duplicate groups and reclaimable space), and explicitly declares the read-only, non-deleting behavior. It omits operational concerns such as hashing cost on large directories and what happens when the scan limit truncates 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?

Three short clauses, each earning its place: method first, use case second, safety guarantee last. No filler and the most decision-relevant content (what it returns, that it does not delete) is front-loaded or clearly flagged.

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, and the description compensates by naming what is returned (duplicate groups plus reclaimable space). What remains missing is the truncation behavior under max_files and the scope of what is not scanned, which matters for a tool that reports completeness of a directory sweep.

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

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

Schema coverage is 100%, so the schema already documents all three parameters with defaults, making 3 the baseline. The description adds conceptual meaning for the size-threshold and size-grouping logic but never mentions the max_files cap or its effect on result completeness, which is the one parameter semantic that would genuinely help an agent.

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 underlying method (size grouping then sha256 on same-size candidates), so the agent knows exactly what the tool computes. It does not name or contrast the nearest siblings (probe_dir, storage_report), so differentiation is inferred from the resource 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?

Offers one concrete use case (清理相册里重复保存的图片) which implies usage, but gives no when-not conditions, no prerequisites, and no pointer to alternative tools for related jobs such as directory probing or storage reporting.

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 burden. '获取' implies a non-mutating read, and the enumerated data categories give a useful preview of returned content, but there is no statement about latency/cost, whether results are cached, or whether it requires any host-level access — meaningful gaps for a tool with zero annotation coverage and no output 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?

A single sentence that front-loads the resource and then lists the covered fields, with no filler or repetition. It is dense but readable; a short clause on the disk-vs-storage_report boundary would have been worth the extra 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?

With no output schema and no parameters, the description does the necessary work by enumerating what the snapshot contains, so an agent knows what it will get back. The remaining gap is structural detail — units, whether values are live or cached, and how this differs from storage_report.

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, which is the baseline-4 case: there is no parameter meaning for the description to add. The schema is empty and fully consistent with the description's claim of an unfiltered whole-host snapshot.

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 (宿主机硬件/运行时快照), then enumerates the concrete fields covered: CPU architecture, OS, memory, disk, Node runtime version, MCP service info. An agent can tell this is a host-snapshot tool, though the description never distinguishes it from the sibling storage_report, which plausibly overlaps on the disk/storage portion.

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 tail clause '供 Agent 决策本地算力分配' implies a use scenario (call it before deciding local compute allocation), but it is framed as a purpose rather than an explicit when-to-use rule. There are no exclusions and no naming of alternatives such as storage_report when only disk figures are needed.

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 meaningful behavior: parsing is pure JS with no ffprobe dependency, unsupported files fall back to magic-number sniffing rather than failing silently, and the operation is a read. It does not state what happens on a nonexistent path, permission denial, or large files, which is the remaining gap 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?

One dense sentence, front-loaded with the verb and resource, with semicolon-separated clauses that each carry distinct information (stream fields, image case, fallback case, implementation note). Nothing is padding, though the clause chain is long enough that a reader must parse it carefully.

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 return values and it does so field by field for each file class. Combined with the absolute-path constraint and the ffprobe-free note, an agent has enough to call it correctly; only error/edge-case behavior is 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?

There is a single parameter with 100% schema description coverage, and the schema already specifies an absolute local path with an example. The closing clause '参数为本地绝对路径' only restates that constraint, adding no new meaning, so the baseline 3 applies.

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

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

The description uses a specific verb (获取/probe) and enumerates exactly what is returned: container, duration, video stream fields (codec/resolution/fps/bitrate), audio stream fields (codec/channels/sample rate/AAC params), plus image dimensions and magic-number sniffing for other files. It is clearly distinguishable from extract_audio_track or probe_dir, but it never explicitly contrasts with read_exif, which also targets image metadata, so the boundary with that sibling is left implicit.

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 file-type breakdown (media files get stream info, images get dimensions, anything else gets magic sniffing), which tells an agent when the tool will still return something useful. However, there is no explicit when-to-use/when-not guidance and no named alternative such as read_exif for EXIF fields or extract_audio_track for audio extraction.

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 exist, so the description carries the full burden. It clearly implies a read-only inspection ('体检', '嗅探') and discloses the inspection techniques (magic-number sniffing) and aggregation behavior, which is useful. However, it does not state how large directories, permission-denied paths, or missing directories are handled, nor the cost of scanning, so an agent cannot predict failure or latency 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 purpose is front-loaded in the opening clause, and the enumeration of per-file fields is dense but readable. The closing comparison sentence earns its place by providing routing guidance. It could be tightened slightly, but there is no filler.

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

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

There is no output schema, so the description must convey return values, and it does describe per-file fields and the category-level totals that an agent can expect. Gaps remain around error cases (nonexistent path, unreadable files) and whether the limit truncates the aggregates, but the core contract is covered.

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

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

Schema description coverage is 100%, so sort, limit, recursive, and dir_path are already fully documented including defaults and enum meanings. The description adds no additional parameter guidance such as when to set recursive or how limit interacts with the per-category totals. 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 gives a specific verb and scope ('批量体检一个目录' — inspect a directory in bulk) and enumerates exactly what is reported per file: magic-number type, size, mtime, video duration/resolution/codec, image dimensions, plus category totals. It also names the sibling it replaces, so an agent can tell it apart from get_video_info immediately.

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 states an explicit alternative and a reason to choose this tool ('比逐个调 get_video_info 省往返'), which is real routing guidance. However, there are no when-not-to-use conditions and it does not relate to other similar siblings such as storage_report, find_duplicates, or read_exif, so the agent must infer whether it subsumes them.

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 reasonably well: it is clearly a read-only inspection, it discloses the extra computed output (是否可信 comparison against file mtime), and it explains that passing a directory switches to a batch aggregation with a sampled subset governed by limit. It does not say what happens for non-JPEG files, images lacking EXIF, or missing paths, which for a read tool with no annotations is the main remaining gap.

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

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

Three tight clauses: what is extracted, the mtime-credibility signal, then the directory batch behavior, then the intended use. Output contents are front-loaded and nothing is redundant or 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?

With no output schema, the description compensates by enumerating the returned EXIF fields and the batch summary statistics (count with EXIF, time span, model distribution), which is what an agent needs to decide to call it. Missing only failure-mode behavior and any note on cost of scanning large directories beyond the limit cap.

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, including the default 50 and cap 200 for limit. The description adds the meaning of the file_path dual mode (file vs directory → single report vs batch summary), but restates rather than extends the limit semantics. Baseline 3 applies 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?

States a specific verb+resource (读取 JPEG 的 EXIF) and enumerates exactly what is extracted: DateTimeOriginal, camera model, GPS, aperture/shutter/ISO/focal length, pixel dimensions, plus a file-mtime credibility check. The directory-mode batch summary is spelled out too, and the JPEG constraint implicitly separates it from the video sibling get_video_info.

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 use case (用于按真实拍摄时间整理相册) and implicitly scopes it to still images, which helps against get_video_info and probe_dir. But it never says when NOT to use it, never names an alternative (e.g. probe_dir for non-EXIF metadata listings), and does not state prerequisites such as the file needing to be a JPEG with an EXIF block.

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 exist, so the description carries the full disclosure burden. It does describe what the analysis returns, but it says nothing about read-only safety, permissions, cost, scan time, or whether the scan recurses. For a recursive filesystem scan with no annotations, those omissions matter.

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 the core capability front-loaded and the use-case cue trailing. The parenthetical file-type list earns its place by previewing the output categories, and nothing is redundant.

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

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

With no output schema, the description compensates by enumerating the returned sections, and all three parameters are fully documented in the schema. The only gap is operational behavior: depth of recursion and performance limits are not stated.

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 path, top, and max_entries are already documented in the schema. The description adds context that the 'top' parameter drives the 'top subdirectories' section and names the file-type buckets, but it adds no format guidance or defaults beyond the schema, 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?

The description uses a specific verb-plus-resource framing ('分析一个目录的空间都去哪了') and enumerates the three result components: top subdirectories, distribution by file type, and largest files. That is enough for an agent to distinguish it from get_video_info or read_exif. It does not explicitly contrast with the overlapping sibling probe_dir, 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 supplies a concrete triggering scenario ('手机空间不够了帮我看看'), so an agent knows the situation that should select this tool. It offers no explicit when-not conditions or named alternatives such as probe_dir or find_duplicates, so it falls short of full routing guidance.

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