Extract text and media evidence from downloaded WeChat attachments, including documents, OCR, local audio/video transcription, and timestamps. Use it to inspect chats for statements and summaries.
提取已下载微信文件正文或媒体证据。支持常见文档、表格、演示、电子书、文本、ZIP文本项、图片OCR，以及音视频本地ASR、关键帧OCR和时间戳证据。
| Name | Required | Description | Default |
|---|---|---|---|
| max_chars | No | ||
| source_path | Yes | ||
| offset_chars | No |
Changes observed during successful MCP inspections.
v4.1.8Input schema / properties / offset_charsAdded value: +{
+ "maximum": 100000000,
+ "minimum": 0,
+ "type": "integer"
+}v4.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it reveals the tool performs heavyweight local processing (local ASR, keyframe OCR, timestamp evidence), which tells an agent this call may be slow/resource-intensive in a way the annotations do not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the core purpose before the format list, with no filler. The format enumeration is long but each item maps to a real capability, so it largely earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and 0% parameter documentation, so the description should carry the burden of explaining return shape and the offset/max_chars pagination contract. It explains neither, leaving an agent unable to know how to page through large attachments or what the extraction result looks like.
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% for three parameters, and the description names none of them. offset_chars and max_chars strongly imply character-windowed pagination, but the description never explains chunking, how to continue extraction, or what source_path accepts, so it fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (提取/extract) and resource (已下载微信文件正文或媒体证据) and enumerates the supported input types (documents, sheets, presentations, ebooks, text, ZIP, images, audio/video). This is far more specific than the bare name, though it never names the close sibling search_wechat_attachment_text to differentiate reading vs. searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '已下载微信文件' implies a precondition (the attachment must already be downloaded) which is useful context. However, there is no explicit when-to-use guidance, no exclusion criteria, and no routing to the obvious alternative search_wechat_attachment_text or list_wechat_attachments, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.