extract_audio_trackExtracts AAC audio tracks from MP4/M4A files into playable raw .aac streams using sample tables and ADTS headers, ready for playback or speech recognition without FFmpeg.
把 mp4/m4a 里的 AAC 音轨按样本表(stsz/stco/stsc)直抽出来，手工构造 ADTS 头写成 .aac 裸流，可直接播放或喂给语音识别。本机无 ffmpeg，故不做重采样/转 WAV。
| Name | Required | Description | Default |
|---|---|---|---|
| input_path | Yes | 源视频绝对路径 | |
| output_path | No | 输出 .aac 路径，省略则同目录同名 |
Changes observed during successful MCP inspections.
v1.3.2Does 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.