Create a meeting bot

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

With no annotations, the description carries the burden. It discloses key behavioral aspects: the bot is sent to a meeting, returns bot_id and transcript_id (when transcription provider is set), and callback_url enables lifecycle webhooks. It doesn't mention cost implications (though idempotency_key hints at no double charge) or rate limits, but for a creation tool it provides sufficient transparency about the action and its outputs.

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 two sentences, front-loaded with the primary action and key return values. Every sentence carries information: the first states what the tool does and the scheduling option, the second explains return values and webhook setup. No fluff or redundancy.

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?

The tool is complex with 16 parameters, but the schema covers all of them. The description provides the high-level purpose, return values, and webhook hint. It doesn't explain error cases or detailed post-creation behavior, but given the schema richness and the description's coverage, an agent has enough to invoke the tool correctly.

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 the baseline is 3. The description text adds value beyond the schema by explaining the overall purpose and return values, but it does not elaborate on individual parameters (which are already well-documented in the schema). No extra meaning is needed beyond the schema, so a 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 action: 'Send a MeetStream bot to a Zoom / Google Meet / Microsoft Teams meeting' and distinguishes it from sibling tools like get_bot_status, list_bots, and schedule_calendar_bot by focusing on creation/scheduling. It also mentions return values (bot_id, transcript_id) and callback_url usage, making the tool's purpose unambiguous.

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 description clearly indicates when to use this tool (to create/schedule a bot) and mentions the scheduling option via join_at. While it doesn't explicitly say 'use this instead of X', the sibling context (e.g., schedule_calendar_bot for calendar events, get_bot_status for status) implies its role. It also highlights the callback_url for lifecycle webhooks, which guides integration decisions.

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