eda_sys_message_bus_pull

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

With no annotations, the description carries the behavioral burden and does provide some useful disclosures: it operates on the private bus, pulls only one message per invocation, and returns a message bus task. It does not disclose whether pulling consumes/removes the message, whether it can block, how the callback is invoked, or what happens when the bus is empty. These are meaningful gaps for a pull 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?

The description is compact and front-loads the function signature, followed by short remarks and return info. There is minimal fluff and no redundant explanation. The mixed-language label '私有消息总线：拉消息' is slightly redundant with the name, but overall the structure is efficient.

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?

Given the large sibling family of message-bus tools and the absence of both annotations and an output schema, the description is under-specified. It does not clarify the relationship to pull_public, pull_async, push, publish, or subscribe, nor does it explain the returned task, callback invocation rules, or empty-bus behavior. An agent would need additional information to use it confidently in non-trivial scenarios.

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?

The schema only exposes a generic args array and a windowId, so it does not document the actual topic and callbackFn parameters. The description compensates by giving the exact signature with types: topic: string and callbackFn: (message: any) => void. This is genuine added value beyond the structured schema, though callback semantics and return-value details remain thin.

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 names a specific operation—pulling a message from the private message bus—and adds a concrete behavioral detail: only one message is pulled per call. The 'private' qualifier helps distinguish it from public-bus siblings. It falls short of a 5 because it never explicitly contrasts with eda_sys_message_bus_pull_public or the async variants.

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 private-bus qualifier implies this tool is for private message bus consumption, and the one-message-per-call remark sets an expectation. However, it gives no explicit guidance about when to choose this over pull_public, pull_async, subscribe, or other message-bus siblings. Usage context is implied rather than stated.

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