eda_sys_message_bus_push

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

With zero annotations, the description carries the full burden and it does add one genuine behavioral disclosure: the remark '每个消息只有一个 Puller 可以收到' (each message is received by only one Puller), which reveals point-to-point rather than broadcast delivery semantics. However, it omits other relevant behavior such as what happens when no puller is subscribed, whether the operation blocks or queues, and it declares no side-effect or safety profile for what is evidently a write operation.

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 compact lines with no fluff: signature first, then a one-line purpose, then a one-line behavioral remark. The front-loading is good and every sentence earns its place. Minor deduction for mixing Chinese and English, which slightly reduces parseability for an English-centric agent.

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 void-returning push operation, the description covers the action, the bus scope, and the consumption semantic, which is close to adequate. But given no output schema and no annotations, the agent is left to infer prerequisites (e.g., whether a private bus must exist via create_private_message_bus), the private/public distinction, and delivery behavior when no puller is waiting — gaps within a very large sibling family.

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?

Although schema coverage is reported at 100%, the schema only describes the generic wrapper params (`args` array in 'official signature order', `windowId`). The real domain parameters `topic: string` and `message: any` appear only in the description's signature line, and the ordering convention lets an agent map args[0]→topic, args[1]→message. This is meaningful semantics the schema alone cannot provide.

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 states a specific verb and resource: '私有消息总线：推消息' (private message bus: push message), backed by a concrete signature `sys_MessageBus.push(topic: string, message: any) -> void`. The '私有' (private) qualifier implicitly distinguishes it from sibling `eda_sys_message_bus_push_public`, though it never names that sibling explicitly and part of the description is in Chinese.

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?

No explicit when-to-use or when-not-to-use guidance. The 'private' label hints at the private-vs-public split, but the message-bus sibling family is huge (publish, subscribe, pull, rpc_call, push_public, etc.) and the description never explains how push relates to publish, when the private bus must be created first, or which alternative to choose. The single-puller remark is a behavioral note, not usage guidance.

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