Broadcast an agent's intended action to the team intent bus, enabling shared visibility and coordination across agents.
意图广播——Agent 广播「我要做什么」到团队意图总线。
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | 意图类型（glob 可匹配：intent.create.report） | |
| source | Yes | 发送者 agentId | |
| target | Yes | 意图目标（文件/实体/key） | |
| payload | No | 意图载荷（可选） | |
| team_id | Yes | 团队 ID |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does not say whether the broadcast is asynchronous, fire-and-forget, persistent, requires team membership, or returns any acknowledgment. The agent is left without knowledge of side effects or expectations.
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 a single sentence with no wasted words and is front-loaded with the core concept. It is slightly repetitive with the tool name ('意图广播' vs 'broadcast'), but overall it is concise.
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 tool with five parameters, no output schema, and no annotations, the description omits important calling context: when to use it, what a caller should expect in return, and what side effects occur. The schema handles parameters, but the overall operational context is incomplete.
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 100%, so every parameter (intent, source, target, payload, team_id) is already documented clearly. The description adds no additional meaning to the parameters, so a baseline score of 3 is appropriate.
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 ('广播' / broadcast) and a specific resource ('团队意图总线' / team intent bus), making the core purpose clear. It doesn't explicitly contrast with sibling tools, and '意图' remains somewhat abstract, but the overall intent is understandable.
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?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. The phrasing 'Agent 广播「我要做什么」' implies an agent announcing plans, but that is only implicit and not actionable selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.