Read WeChat posts, articles, link cards, or long text by session ID and local message ID; use keyword hints to find indexed variants. External webpages are not fetched.
读取微信聊天中的帖子、文章、链接卡片或长文本。先按session_id + local_id精确回查，再用有限关键词查询补充索引变体；外部网页不会自动联网抓取。
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| local_id | Yes | ||
| page_size | No | ||
| scan_limit | No | ||
| session_id | Yes | ||
| max_queries | No | ||
| keyword_hint | No |
Changes observed during successful MCP inspections.
v4.1.8Input schema / properties / offsetAdded value: +{
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / page_sizeAdded value: +{
+ "exclusiveMinimum": 0,
+ "maximum": 100,
+ "type": "integer"
+}Input schema / properties / scan_limitAdded value: +{
+ "exclusiveMinimum": 0,
+ "maximum": 20000,
+ "type": "integer"
+}v4.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing the local index lookup strategy and reinforcing that no live web fetch occurs, giving useful behavioral context about what will and will not be returned.
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 focused sentences with the core purpose front-loaded, followed by the retrieval approach and boundary. No filler, though the external-page caveat partly restates the openWorldHint=false annotation.
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 7-parameter tool with no output schema and 0% schema description coverage, the description covers purpose, strategy and one boundary but leaves four pagination/query-limit parameters unexplained. It is adequate to select the tool but incomplete for invoking it confidently.
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% across 7 parameters, so the description carries the full burden. It does explain the role of the required session_id + local_id (exact back-lookup) and implies keyword_hint (关键词查询), but offset, page_size, scan_limit and max_queries remain entirely undocumented in both schema and 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?
Names a specific verb (读取) and resource (帖子、文章、链接卡片或长文本 within WeChat chats), which is concrete enough to distinguish from sibling readers like get_message_by_id or fetch_wechat_article. It does not explicitly name which sibling to prefer in overlapping cases, so it falls short of 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 describes a two-step retrieval strategy (exact session_id + local_id lookup, then bounded keyword index queries) and notes a boundary — external web pages are not fetched. However, it never states when to choose this tool over the many sibling article/message readers, leaving the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.