The async lifecycle (read_start → read_result → read_reply) is clearly separated, and wecom_read is a distinct synchronous read path. The main overlap is between capabilities and status (both are informational diagnostics), plus a potential question of when to use read_start versus wecom_read, though the descriptions do draw the line at async remote tasks versus direct token reads.

All tools share the dayuan_ prefix and snake_case, making names predictable and collocation-friendly. The only deviation is word order: read_start/read_result/read_reply put the action verb first, while wecom_read puts the resource first, and capabilities/status are noun-only.

Six tools is a well-scoped count for a read-only gateway whose purpose is to expose a query lifecycle plus one direct read path. Four of the six slots are consumed by the async task lifecycle, but each of those serves a necessary step (submit, poll, clarify).

The read lifecycle, capability discovery, and WeCom data reads are covered, but there is no way to cancel or abandon a submitted query, no listing of in-flight request_ids, and no continuation mechanism for oversized results. File and attachment reads are explicitly excluded, which is defensible but leaves a real gap for document workflows.