broadcast_messageSend one message to multiple configured bots at once, optionally choosing recipients or omitting them to reach every bot, while sharing a thread ID so replies stay in one transcript.
Send the same message to several configured bots. Omit bots to send to every bot. One threadId is shared so the transcript stays together.
| Name | Required | Description | Default |
|---|---|---|---|
| bots | No | Bot ids. Omit for every bot. | |
| context | No | ||
| message | Yes | ||
| threadId | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a mutating, open-world operation; the description adds that a single threadId is shared so transcripts stay grouped, and that omitting bots fans out to every bot. That default-broadcast blast radius is meaningful behavioral context beyond the annotations. It still omits permissions or error behavior.
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 short sentences, front-loaded with the action and followed by the two operative details (omission default and thread sharing). Nothing is padded or redundant.
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 four-parameter broadcast tool with annotations and no output schema, it covers the key call-shaping facts: fan-out scope and shared thread identity. The main remaining gap is the unexplained 'context' parameter and any permission or rate-limit behavior.
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 only 25%, and the description explains two of the four parameters: bots omission semantics and the shared threadId mechanism. 'context' and 'message' receive no explanation in either place, so the description only partially compensates for the sparse schema.
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 uses a concrete verb and resource ('Send the same message to several configured bots') and makes the broadcast scope explicit. It distinguishes itself from send_message through 'several bots' but never names the sibling, leaving that inference to the agent.
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 gives one conditional rule ('Omit bots to send to every bot') but says nothing about when to choose this over send_message or relay_conversation. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.