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.

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

Beyond the destructiveHint annotation, the description discloses that deletion is permanent and irreversible, that it fires a data_deletion webhook, and that it requires explicit user consent. This gives an agent meaningful behavioral context for a destructive 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?

Two sentences carry all essential information: the action, the scope, the irreversibility, the webhook side effect, and the invocation condition. There is no filler or repetition beyond the acceptable emphasis on permanence.

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 simple destructive tool with two required parameters and no output schema, this description is complete. An agent knows what will be deleted, that it is permanent, that a webhook fires, and that explicit user consent is required, so it can decide whether and how to invoke the tool.

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 50%; the confirm parameter is already well documented in the schema. The description reinforces the consent requirement and clarifies what data is affected, but it does not elaborate on bot_id or add parameter-level detail that meaningfully compensates for the undocumented parameter.

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 verb and resource: permanently delete a bot's audio, video, and transcripts. It is clear about scope and permanence, though it does not explicitly compare itself to the sibling remove_bot, leaving the agent to infer the difference from the data-vs-bot naming.

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 gives a clear usage boundary: only call when the user explicitly asks to delete data. This implies when not to use it, but it does not name alternative tools like remove_bot or explain how choosing between them should be decided.

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

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

The readOnlyHint annotation already signals a safe read operation, and the description adds meaningful behavioral context by listing the exact metadata fields returned. It also clarifies that transcript_id is the canonical source and that caption_file is provider-specific, which helps an agent interpret the result.

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 dense line with no wasted words. It front-loads the core purpose and then lists concrete return fields, with useful parenthetical clarifications for transcript_id and caption_file.

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 simple single-parameter read-only tool, the description adequately explains what the agent will receive, including special cases like meeting_captions provider. It does not explain where bot_id comes from, but the low complexity and sibling tool context make this a minor gap.

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 0%, and the description does not explain bot_id, its format, or how to obtain it. The single required parameter is easy to infer from the tool name, but the description adds no semantic value beyond the bare schema definition.

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 specific verb-resource pair and immediately defines what the tool returns: full session metadata with enumerated fields such as platform, duration, timings, status timeline, transcript_id, caption_file, and original request payload. This clearly differentiates it from sibling tools like get_bot_status and get_bot_summary.

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 phrase 'Full session metadata' implies this is the tool to use when comprehensive session details are needed, but there is no explicit contrast with get_bot_status, get_bot_summary, or get_transcript. Usage is inferable rather than directly stated, and no when-not-to-use guidance is given.

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

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

The annotations already declare readOnlyHint=true, so the description doesn't need to repeat that. It adds value by listing the exact status values an agent can expect, including error states like 'Error' and 'Denied'. This gives useful behavioral context beyond the annotation without contradicting it.

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, concise sentence that front-loads the purpose and then lists the possible values. Every word earns its place; there is no fluff or redundant phrasing. It is optimally structured for quick comprehension.

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 that this is a simple read-only status tool with one parameter and no output schema, the description provides the essential context: what the tool does and what values to expect. It could mention the return format or error handling, but the status list already covers error conditions. The missing parameter explanation is a minor gap, making it nearly complete for its simplicity.

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 sole parameter bot_id has zero schema description (coverage 0%), and the tool description does not mention it at all. While the parameter name is self-explanatory, the description does not state that bot_id identifies the bot whose status is being retrieved. This is a gap for a single required parameter with no schema documentation.

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 clearly states the tool returns the current bot status and enumerates all possible values (Joining, InWaitingRoom, etc.). This is a specific verb-resource combination (get status) and distinguishes it from get_bot_detail and get_bot_summary, though it doesn't explicitly name those alternatives. It is unambiguous and informative.

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 the sibling tools like get_bot_detail or get_bot_summary. The description simply states what it does, leaving the agent to infer that status is distinct from detail or summary. No exclusions or alternative conditions are provided.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds context that the summary is generated by MeetStream's built-in AI rather than an external LLM, which is useful. It does not disclose return format, latency, or whether the summary is precomputed, but no contradiction exists.

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?

A single, tightly written sentence that front-loads the core purpose and adds one meaningful qualifier. Every word earns its place; there is no filler or redundant restatement of the tool name.

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 one-parameter read-only getter, the description names the resource and scope adequately. However, with no output schema, it does not indicate what the response contains, and it does not clarify bot_id provenance or route the agent among the summary/transcript/detail sibling tools. It is minimally viable but has clear gaps.

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 0% and the description never mentions bot_id. While 'bot_id' is somewhat self-explanatory, the description adds no meaning about what the ID represents, where to obtain it, or how it relates to sibling tools like create_bot. The description fails to compensate for the low schema coverage.

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 specific verb and resource: getting MeetStream's built-in AI meeting summary, and adds a useful differentiator with 'no external LLM needed.' It does not explicitly distinguish this from sibling tools like get_transcript or get_bot_detail, but the core purpose is clear.

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 phrase 'built-in AI summary' and 'no external LLM needed' implies this is the tool to use when you want MeetStream's own summary rather than raw transcript or external processing. However, it never names alternatives or states when not to use this tool, leaving usage guidance mostly implicit.

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

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

The readOnlyHint annotation already signals that this is a safe read operation, and the description adds little beyond that: 'captured during the meeting' mostly restates the title. It does not disclose behavior such as ordering, pagination, message fields, whether empty results are possible, or how returned chats relate to the transcript.

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 short, but the brevity is under-specification rather than economical completeness. It omits essential semantic content about the parameter and usage context, so the single sentence does not earn its place as a sufficient definition.

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 simple one-parameter tool, the description still leaves a critical gap: it never explains that bot_id identifies the meeting/bot whose chats should be returned. With no output schema and no param descriptions, this is not enough context for an agent to invoke the tool correctly with confidence.

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 0%, and the single required parameter bot_id is completely undocumented in both the schema and the description. The agent receives no explanation of what bot_id represents, how to find it, or what format it should take, so it cannot reliably populate the only required argument.

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 identifies a specific resource ('chat messages') and the context ('during the meeting'), and the title clarifies the action as 'Get'. It is clear enough to be understood as a retrieval tool for in-meeting chat, though it does not explicitly differentiate itself from siblings such as get_transcript or send_chat_message.

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 guidance is given on when to use this tool versus alternatives like get_transcript or send_chat_message. The phrase 'during the meeting' provides some context, but there is no scenario, exclusion, or mention of a preferred alternative.

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

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

Annotations already declare readOnlyHint=true; description adds behavioral context beyond that: presigned URL validity (1h/10min) and creation-time prerequisites for stream kinds. No contradiction, but doesn't mention response shape or empty-result 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?

A single, dense sentence front-loads the core purpose and packs in all essential kind distinctions without redundancy. Every clause adds value.

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?

Covers purpose, kinds, validity, and prerequisites adequately for a simple read-only tool with no output schema. Missing explicit return format, but annotations and purpose imply a simple list of URLs.

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 coverage is 0%, so the description must compensate. It thoroughly explains the kind enum (validity, per-participant requirement) but leaves bot_id undocumented, relying on convention from sibling tools.

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?

States a specific verb+resource: 'Presigned S3 URLs for recorded media.' Clearly distinguishes from siblings like get_transcript (text) and get_bot_status (status), and enumerates the media kinds returned.

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?

Implied usage from title and purpose, but no explicit when-to-use vs alternatives. Provides kind-level prerequisites (e.g., separate_*_streams for per-participant streams), which helps choose a kind, but not tool-level selection guidance.

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

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

The readOnlyHint annotation already establishes this as a non-destructive read, and the description does not contradict it. The description adds a little context by noting that participants are 'detected' and listing output fields, but it does not disclose more behavioral traits such as auth requirements, empty-result behavior, or rate limits.

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 one compact, front-loaded sentence with no filler or redundant explanation. It efficiently conveys the resource and expected output fields.

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 simple with one parameter and no output schema, so the listed field names provide basic context. Still, the meaning of bot_id, the notion of 'detected', and the structure or statuses of the returned participants are not explained, leaving minor but real gaps.

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 0%, and the description does not explain what bot_id represents or how it relates to the meeting participants. The sole parameter is left completely to inference from its name, so the description adds no semantic value beyond the 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 states a specific verb and resource: retrieving participants detected in the meeting, and enumerates the returned fields (displayName, fullName, status, stream ids). It is clearly distinct from sibling tools such as get_transcript, get_chats, or get_bot_detail, which concern different resources.

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 phrase 'Participants detected in the meeting' implicitly signals that this tool should be used when the caller needs the participant list for a meeting. However, it provides no explicit when-to-use vs alternatives, no prerequisites, and no exclusions or conditions.

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

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

The annotations already mark the operation read-only, so no safety disclosure is needed. The description adds a small amount of behavioral context by indicating the output is a chunk timeline with speaker ids/names, but it does not disclose ordering, chunk boundaries, or response format.

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?

A single compact sentence conveys the core result and its format without filler. The key output information is front-loaded.

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 single-parameter read-only tool, the description is minimally sufficient, but it leaves the exact response shape and the role of bot_id implicit. More detail on the returned chunks or explicit linkage to the bot would make it complete.

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 0% and the description never mentions bot_id or explains what bot the timeline belongs to. The parameter name is simple, but the description fails to compensate for the absent schema documentation.

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 clearly identifies the resource (a chunked speaker timeline) and what it contains (speaker ids/names and when they spoke), which distinguishes it from related tools like get_transcript or get_participants. It lacks an explicit verb, but the tool name supplies the action.

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 phrasing 'Who spoke and when' implies the use case for retrieving a speaker-segmented timeline. However, it gives no explicit guidance on when to choose this tool over siblings such as get_transcript or get_participants.

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

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

Beyond the readOnlyHint annotation, the description discloses significant behavior: the automatic transcript_id resolution, the polling mechanism with wait, and the output fields (speaker, transcript). This adds substantial context that annotations alone do not provide, and there is no contradiction.

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 concise and front-loaded with the core purpose. Each sentence adds value (auto-resolution, wait behavior, output fields). It is not overly verbose, though it could be slightly more structured with bullet points, so a 4 rather than 5.

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 read-only tool with no output schema, the description covers the key flow: fetching by bot_id, auto-resolution, polling, and output structure. It does not address error cases or pagination, but these are minor given the simplicity. It is reasonably complete, so a 4.

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 coverage is 75%, so the baseline is 3. The description adds context for the wait parameter (poll until ready after a specific event) and clarifies bot_id's role, but it does not explain raw or timeout_seconds beyond the schema. The added value is modest, 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 clearly states the verb 'Fetch' and the resource 'transcript by bot_id', with the added detail that it resolves transcript_id automatically. It distinguishes itself from a simple list operation by mentioning the auto-resolution, but it does not explicitly name a sibling alternative, so it falls short of a 5.

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 explains the context for using wait=true (poll until ready after transcription.processed fires) and the reason the tool exists (transcript_id is not in webhooks, so it resolves it via /detail → /transcriptions). It gives clear when-to-use guidance but does not explicitly state when not to use it or name alternatives.

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

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

readOnlyHint already covers the read-only safety profile. The description adds genuine value by disclosing pagination behavior and the exact response shape (bots[], hasNextPage, nextCursor), which is not available from the annotations or schema.

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?

One compact sentence front-loads the core action ('List all bots on the account') and adds the pagination detail in parentheses without waste. Every element earns its place.

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 zero-parameter, read-only list tool, the description is nearly complete: it covers account scope and return pagination fields. It does not describe the per-item fields inside bots[], but the low complexity and absence of an output schema make this a minor gap.

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?

There are zero parameters, so the description carries no parameter burden. The empty input schema is fully covered by the description's lack of parameter discussion, matching the baseline for a parameterless tool.

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 ('List'), resource ('all bots on the account'), and scope, clearly distinguishing it from singular bot tools like get_bot_detail or get_bot_status. The pagination note further confirms this is the aggregate listing tool.

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 purpose implies when to use it—when the agent needs all bots on the account—but it never names alternatives or exclusions. An agent could still hesitate between this and get_bot_detail for individual bot lookups, so the guidance remains implicit rather than explicit.

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

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

Annotations declare readOnlyHint=true, so the description need not repeat that. It adds value by noting OAuth credentials are needed and that the connection is usually done once, but it doesn't disclose potential rate limits, data freshness, or what happens if no calendars are connected. No contradiction with annotations.

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 parenthetical sentence that is concise and readable. It front-loads the core action 'Upcoming events' and then the setup detail, which is efficient. No filler words.

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 zero parameters, no output schema, and a readOnlyHint annotation, the description is fairly complete. It explains the source and the pre-requisite setup, which is important. However, it lacks clarity on the date range of 'upcoming' and what the returned events include, which an agent might need to decide if this is the right tool.

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?

There are zero parameters, and the schema has no properties. The description clarifies the source (connected Google Calendars), which is essential context. Since there are no parameters to document, a baseline of 4 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 it lists upcoming events, but it's vague about what 'upcoming' means and doesn't distinguish it from the many sibling tools. The verb and resource are clear, but the scope is ambiguous and does not differentiate from scheduling tools.

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 mentions a prerequisite for connecting Google Calendars, which is useful but not directly a usage guideline for when to call this tool. There is no guidance on when to use this vs. alternatives, and the connection detail is more about setup than invocation.

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

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

Annotations already mark the tool as read-only, and the description adds useful behavioral detail: it returns transcript_id, provider, status, and presigned download URLs valid for one hour. This goes beyond the annotation by explaining output contents and a time-based constraint, though it does not cover pagination or ordering.

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 one concise sentence that front-loads the core purpose and then lists the important return fields. Every word earns its place, with no fluff or repetition of the title.

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 simple list endpoint with one parameter and read-only annotations, the description covers the essential return values and the URL expiry caveat. It is complete enough to call correctly, though it omits potential pagination or empty-result behavior; this is a minor gap given the tool's simplicity.

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 provides no description for bot_id (0% coverage), but the description clarifies it refers to the bot whose transcription runs are being listed. The parameter is a single obvious identifier, so the description partially compensates for the missing schema documentation, though it does not specify the format or source of bot_id.

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 clearly states the resource ('transcription runs for a bot') and the scope ('All'), and lists the key fields returned. This makes it easy to distinguish from sibling tools like get_transcript, which implies a single transcript, and transcribe_audio, which creates one.

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 explicit guidance on when to use this tool versus alternatives such as get_transcript or transcribe_audio. The description implies it is for listing runs, but it does not state when a user should choose this instead of a sibling.

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

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

With no annotations, the description carries the transparency burden. It is upfront that the action is immediate and that recorded data is preserved, and it names the erase tool for the destructive counterpart. It does not cover permissions or failure behavior, but the key side effect is disclosed.

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?

Two sentences with the core action first and the retention caveat second; every word contributes and there is no 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?

For a one-parameter action with no output schema, the description covers what happens, the active-meeting prerequisite, and the data-retention consequence. It omits only minor details such as error conditions or return shape.

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 coverage is 0% and bot_id has only a type/required marker, but the description's subject 'the bot' makes the parameter's role inferable. It adds no format, source, or default details, so compensation is partial.

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 opens with a specific verb and resource: 'Make the bot leave an active meeting now.' It also differentiates itself from delete_bot_data by explicitly stating 'Recorded data is KEPT,' so an agent can separate removal from deletion.

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 specifies the operating context ('an active meeting') and points to delete_bot_data as the alternative when data should be erased. It does not enumerate other siblings or edge cases, so it falls just short of exhaustive routing guidance.

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

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

With no annotations provided, the description must carry the burden of behavioral disclosure, but it only says a bot is 'sent' or 'removes it'. It does not clarify whether unschedule destroys the bot, changes the event, is idempotent, or requires prerequisites. The ambiguity between removing a calendar association and deleting a bot is a material gap.

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?

A single sentence that front-loads the action=schedule behavior and then the action=unschedule counterpart. Every element earns its place and there is no fluff.

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 simple (two parameters, one required) and the core call is clear, but with no output schema or annotations the description leaves missing details such as expected result, error behavior when the event or bot does not exist, and whether there is any effect on the event itself.

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 0%, so the description must add meaning; it does explain what both action enum values do. event_id is not detailed beyond 'specific calendar event', which is thinly supplemented by the parameter name and required flag rather than by the description.

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 resource (a bot relative to a calendar event) and concrete verbs: 'sends a bot' and 'removes it'. It is clear what the tool does and is distinguishable from get_bot_status/remove_bot by the event targeting, though 'removes it' could momentarily be read as deleting the bot resource itself.

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 action-value mapping implies when to call the tool, but there is no explicit guidance about when to prefer schedule_calendar_bot over create_bot or remove_bot, and no conditions or prerequisites are stated.

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

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

With no annotations, the description carries the behavioral burden. It correctly signals that this is a write operation ('Post') and that it requires a 'live meeting' and a bot. However, it does not disclose prerequisites like whether the bot must already be in the meeting, message constraints, or failure/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?

One direct sentence with no filler: it front-loads the action, target, and mechanism. Every word contributes meaning, and nothing is 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 simple send operation, the description covers the core action, but it omits response/return behavior, error cases, and preconditions. With no output schema and no annotations, an agent has limited information to confirm that the call succeeded or to debug failures.

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?

Both parameters have no schema descriptions (0% coverage), and the description does not explicitly map bot_id and message. It only vaguely implies that message is the chat content and bot_id identifies the bot, without specifying types, formats, or constraints beyond what the schema already states.

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 specific verb, 'Post,' and clearly identifies the resource ('a chat message'), the target ('the live meeting'), and the mechanism ('through the bot'). This distinguishes it from siblings like send_image, which sends an image rather than a chat message.

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 intended use is implied: when you need to send a chat message to a live meeting via a bot. However, there is no explicit guidance on when to use this instead of alternatives, such as send_image, or any exclusions.

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

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

With no annotations, the description must disclose behavioral traits. It only states the action and the public URL requirement, omitting side effects (e.g., whether it replaces the existing frame, persists, or affects ongoing video), permissions, or rate limits. The display_duration_seconds parameter is not explained, leaving behavioral ambiguity.

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 concise, two short sentences with no filler. The critical action and the public URL requirement are front-loaded. It earns a high score for efficiency, though it could be slightly more structured by separating the action from the constraint.

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 no output schema, no annotations, and 0% schema coverage, the description is inadequate. It does not explain return values, error conditions, or the behavior of display_duration_seconds, leaving an agent unsure about invocation details. A mutation-like tool with multiple parameters needs far more context.

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 coverage is 0%, so the description must compensate. It adds meaning for img_url (must be public) but does not clarify bot_id (obvious from context) or display_duration_seconds (its purpose, optionality, or bounds). With 3 parameters and only partial coverage, the description falls short.

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 ('Display') and resource ('image/GIF as the bot's video frame'), clearly distinguishing it from sibling tools like send_chat_message. The public URL constraint adds precision without ambiguity.

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 guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or relationships to siblings like send_chat_message or schedule_calendar_bot. The only usage hint is the public URL requirement, which is about parameter constraints, not tool selection.

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

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

No annotations are provided, so the description carries full burden. It fails to disclose that this is likely an asynchronous operation, that re-transcription may overwrite existing transcripts, or any permission/rate-limit considerations. It only implies it runs post-call.

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?

Two sentences with zero filler. The action is front-loaded and the use case is a single clause.

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 4 parameters, no output schema, and no annotations, the description is too brief. An agent cannot know what the function returns, whether the transcription is asynchronous, or what prerequisites exist (e.g., bot must have recorded audio).

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% (callback_url described). The description mentions 'provider' and 'language' in prose but does not explain bot_id, language format, or behavior of callback_url. It adds some context but not enough to compensate 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 states a specific verb ('Start'), resource ('a bot's recorded audio'), and adds the re-run capability, distinguishing it from read-only transcript retrieval siblings like get_transcript. It does not explicitly name siblings, but the action is 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?

It provides a concrete use case: 'to try a different provider or language after the meeting.' This covers when to use it, though it doesn't mention exclusions or alternative tools (e.g., get_transcript) explicitly.

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

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

The readOnlyHint annotation already establishes this is a safe, non-mutating call. The description adds that it is a reference and lists its content, but does not disclose much beyond that, such as return format or any live-verification behavior hinted at in the title.

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?

Two sentences with no wasted words. The first sentence front-loads the purpose and scope, and the second gives a direct usage directive.

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 parameterless, read-only reference tool, the description is complete: it names the topic, the exact areas covered, and when to use it. No output schema exists, but a guide tool's output is adequately implied by its reference nature.

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?

There are zero parameters and the schema coverage is trivially 100%, so there is no parameter documentation burden. The baseline of 4 applies; the description needs to explain no input semantics.

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-resource pair: an authoritative reference for MeetStream webhook events. It clearly enumerates what it covers (envelope shape, full event list, bot.stopped model, provider caveats), distinguishing it from the operational sibling tools.

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 explicitly instructs the agent to 'Use this before writing any webhook handler,' which is a clear trigger for when to consult it. No sibling tool serves as a webhook reference, so no alternative routing is needed.

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