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

No annotations are provided, so the description must carry the full burden. It states 'Append a content block', implying a mutation (adding to the broadcast), but lacks details on ordering, state requirements (e.g., draft vs. sent), or effects on existing blocks. The mention of block types mapping to Slack Block Kit is helpful but not enough for higher score.

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, no wasted words. The first sentence states the primary action; the second adds usage guidance and block type context. Information is front-loaded and 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?

No output schema exists, but the description does not mention return values or success/error states. With 5 parameters (3 required), it omits guidance on optional parameters like 'position' and 'audience_visibility'. Given the complexity of block composition, more detail on behavior and response is needed.

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% across 5 parameters, so the description must compensate. It clarifies the 'type' parameter by mapping to Slack Block Kit, but provides no meaning for 'content', 'position', 'audience_visibility', or 'broadcast_id'. The 'position' parameter is especially unclear given the 'Append' verb. Description adds minimal value beyond type.

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 'Append a content block to a broadcast' with a specific verb and resource. It also references Slack Block Kit types and distinguishes itself from the sibling 'set_broadcast_content' by specifying a different use case.

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 explicitly provides guidance: 'For composing a whole broadcast body, prefer set_broadcast_content (Markdown in, blocks out).' This tells the agent when to use this tool versus the alternative, fulfilling the usage guidelines dimension thoroughly.

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 must carry the full burden of behavioral disclosure. It adds that already-posted messages remain, but omits details about permissions, reversibility, error states, or what happens to scheduled vs in-flight broadcasts differently. This is insufficient for a mutation tool.

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 short sentences with no unnecessary words. However, it could be slightly expanded to include parameter context without losing conciseness.

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 tool has one parameter, no output schema, and no annotations, the description is too minimal. It lacks information about the broadcast_id parameter, return values, error conditions, and prerequisites. More context is needed for an agent to use it 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?

The schema has one required parameter (broadcast_id) with no description in the schema or JSON (0% coverage). The description does not explain what broadcast_id is, how to obtain it, or its format. The parameter is left completely unexplained.

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 action (cancel) and the resource (broadcast), and distinguishes between scheduled/in-flight vs already-posted messages. It is specific and differentiates from sibling tools like schedule_broadcast and send_broadcast_now.

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 implies when to use (to cancel a broadcast), but does not provide explicit guidance on when not to use it or mention alternatives. Given the straightforward nature of cancellation, it is adequate but lacks context relative to the many sibling tools.

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 full burden. It discloses that channels the bot hasn't joined return warnings with code 'bot_not_in_channel' and that sends to those channels fail. This adds significant behavioral context beyond the 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?

The description is two sentences, front-loaded with purpose, and every sentence adds value. No unnecessary words 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?

Given no output schema, the description partially explains return behavior (warnings) but does not specify the full return structure (e.g., audience ID). It also lacks prerequisites or side effects. Adequate but incomplete for a creation 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 coverage is 0%, but the description does not explain individual parameters beyond mentioning 'explicit list of channel ids'. The 'name' and 'description' parameters have no added meaning. The description does not compensate for the lack of schema descriptions.

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 creates a saved audience from an explicit list of channel IDs, using a specific verb and resource. It distinguishes itself from siblings like 'list_audiences' or 'suggest_audiences' by focusing on explicit IDs.

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 implies usage when you have an explicit list of channel IDs but does not explicitly state when to prefer this over alternatives like 'suggest_audiences'. No when-not-to-use guidance is 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?

With no annotations, the description carries the full burden. It discloses that the tool creates a 'draft' broadcast and returns a new id. While it doesn't detail authorization or idempotency, the behavior is clearly a safe creation action. Adequate for a simple tool.

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, front-loaded with the action, no wasted words. Efficient and to the point.

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 3-parameter tool with no output schema, the description covers required and optional inputs, the return value, and a pointer to a related sibling tool. It is fully adequate for an agent to use 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 coverage is 0%, but the description adds meaning by naming the title and sending profile, and stating that audience_ids is optional. It also references a sibling tool for setting channels, providing context 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 clearly states the action (create a draft broadcast) and identifies the required inputs (title and sending profile). It also distinguishes the tool from siblings by noting that target audiences are optional and that ad-hoc targeting should use set_one_time_channels.

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 provides explicit guidance: target audiences are optional at creation, and if needed, use the sibling tool set_one_time_channels for ad-hoc targeting. This tells the agent when and how to use this tool versus an 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?

The description states 'Create,' implying a write operation, but with no annotations, it lacks critical behavioral details. It does not mention idempotency, error handling, authorization requirements (e.g., whether the user needs specific permissions), or what happens if a profile with the same name exists. For a creation tool, these omissions hinder agent judgment.

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 unnecessary words, achieving conciseness. It front-loads the core action and key components. However, it sacrifices completeness for brevity.

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 6 parameters, no output schema, and zero annotations, the description is far from sufficient. It fails to explain the return value (e.g., the created profile object), validation rules, side effects, or how the tool fits into a typical workflow (e.g., creating a sending profile before sending broadcasts). The agent would need to guess these details.

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 description only covers 3 of 6 parameters: display_name (as 'display name'), avatar (presumably avatar_url), footer (footer_text), and default_audience_ids (as 'optional default audiences'). It omits the required 'name' parameter entirely and the optional 'description' field. With 0% schema description coverage, the description should compensate but 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 clearly states the tool creates a resource ('sending profile') and lists included components (display name, avatar, footer, optional audiences). It distinguishes from siblings like list_sending_profiles by focusing on creation. However, it does not explain what a sending profile is used for, leaving some ambiguity about its role in the broader system.

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 provided on when to use this tool versus alternatives. For example, it doesn't mention that users should first create audiences via create_audience if they want to set default_audience_ids, or that listing profiles might be needed before creation to check for duplicates. The tool is presented in isolation without context for its appropriate use.

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 details. It explains the scope (only reactions on Stet's messages and limited to retention window), but does not cover error behavior, auth requirements, or response format, leaving gaps for a safe read 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 brief and well-structured: the first sentence states the core purpose, followed by two clarifying constraints. No unnecessary 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?

For a simple retrieval tool with one parameter and no output schema, the description covers the key aspects: aggregation levels, scope limitation, and retention window. However, it does not mention pagination or error cases, which are minor gaps 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 input schema has 0% description coverage for the single parameter broadcast_id. The description does not explain what broadcast_id is, its format, or how to obtain it, providing minimal guidance beyond the schema's existence.

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 it provides emoji reaction totals aggregated by overall, emoji, and channel, specifying that only reactions on Stet's own messages are counted, which distinguishes it from other 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?

The description lacks guidance on when to use this tool versus siblings like get_broadcast_replies or get_broadcast_sends. No explicit when-to-use or when-not-to-use information is 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?

Discloses ordering, included fields, optional filtering, and retention limit. No annotations provided, so description carries the burden well.

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, concise and front-loaded with key info. Every word 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?

Given no output schema, describes essential return fields (display name, permalink) and ordering. Could mention pagination but adequate for simple 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?

0% schema description coverage; description explains broadcast_id is required and slack_channel_id is optional, but no further details like format or constraints.

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?

Clearly states it retrieves in-thread replies to a sent broadcast, ordered newest first, with display name and permalink. Distinct from sibling tools like get_broadcast_reactions.

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?

Tells when to use (get replies) and mentions optional filtering. No explicit when-not-to-use, but context is clear.

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 provided, so description bears full burden. Discloses it returns delivery data for sent broadcasts, implying read-only behavior. Does not mention permissions or limitations, but covers key behavioral aspects.

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 efficiently convey content and usage. First sentence enumerates returned fields, second sentence provides usage context and sibling distinction. No wasted 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?

With a single parameter and no output schema, the description adequately lists returned fields. Could mention the return structure more explicitly (e.g., array of channels), but the phrase 'per-channel' suffices. Overall sufficient for an agent.

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 explicitly describe the broadcast_id parameter. While the tool name and context make it obvious, the description adds no additional meaning beyond what the schema provides.

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 it returns per-channel delivery results including status, error message, Slack permalink, reply/reaction counts, and a summary. It differentiates from sibling get_broadcast_status which returns draft content.

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?

Explicitly says 'Use this to answer 'did it land?'' and contrasts with get_broadcast_status, providing clear when-to-use guidance and distinguishing from a sibling tool.

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 full burden. It describes the return content and explicitly states what is not returned, adding behavioral context. However, it does not mention prerequisites (e.g., broadcast existence) or error conditions, but for a simple read operation, this is adequate.

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 concise sentences with no wasted words. The first sentence states the primary purpose, and the second provides a crucial exclusion. Front-loaded and 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 tool's simplicity (1 param, no output schema, no annotations), the description is fairly complete. It states what is returned and what is not, distinguishing from a key sibling. It could benefit from mentioning the return format or structure, but it covers essential 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% for the single parameter broadcast_id. The description implies its usage by saying 'Return a broadcast's row,' which adds meaning beyond the schema's minimal type definition. It compensates for the lack of schema 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?

Description clearly states the tool returns a broadcast's row, target audiences, and content blocks. It explicitly distinguishes from sibling get_broadcast_sends by noting what it does not include, making the purpose specific and 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 provides a clear alternative: 'use get_broadcast_sends for delivery status.' This tells the agent when to use this tool versus a sibling, which is excellent 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?

No annotations are provided, so the description carries full burden. It only states that the tool lists audiences, with no disclosure about pagination, ordering, filtering, authentication needs, rate limits, or any side effects. This is insufficient for an agent to fully understand the tool's 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?

The description is a single, concise sentence that delivers the essential information without any redundant or unnecessary 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?

The description is adequate for a simple list-all tool with no parameters and no output schema, but it lacks details about the return format (e.g., list of audience IDs, names, or objects), any ordering, or potential limitations (e.g., maximum return size). Given the tool's simplicity, it meets the minimum but could be more helpful.

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 input schema has zero parameters, so parameter documentation is not needed. The description does not add any parameter meaning, but since there are no parameters, 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 clearly states the action ('List'), the resource ('saved audiences'), and the context ('in this workspace'). It also defines what audiences are ('named sets of channels'), distinguishing it from sibling tools like create_audience (creation) and suggest_audiences (suggestion).

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 implies the tool is used to list all saved audiences but provides no explicit guidance on when to use it versus alternatives like suggest_audiences or list_channels. No 'when not to use' or alternative tool mentions are present.

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?

Without annotations, description carries full burden. It discloses ordering (newest first), returned fields, and scope (workspace). No destructive behavior indicated; safe read 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: first describes output, second gives use case. No wasted words, front-loaded with key info.

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 essential aspects: what is returned, ordering, optional filter, and primary use case. Lacks pagination details or explicit workspace scope, but sufficient for a simple list tool with no output schema and few parameters.

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 has one optional array parameter with enum. Description mentions 'Optionally filter by status', adding that it's optional, but does not detail enum values or usage. Schema description coverage is 0%, so description adds moderate value.

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?

Description clearly states it lists broadcasts with specific fields (status, counts, send time, preview) and optional filtering, distinguishing it from siblings like preview_broadcast and get_broadcast_status.

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?

Explicitly states 'Use this to find a broadcast's id before calling the engagement tools', giving a clear use case. However, lacks explicit when-not-to-use or alternatives, though implied.

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 bears full responsibility for behavioral disclosure. It only states 'list' which implies read-only, but lacks details on pagination, rate limits, access scopes, or what constitutes a 'channel' (public vs private).

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, front-loaded with purpose, no redundant information. Efficient and clear.

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 and simple parameters, the description provides the core function but lacks details on return value structure, sorting, or limitations. Adequate but could be more 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%, so description compensates minimally by stating 'free-text query' and 'structural filters' with properties has_bot and is_private. However, it does not explain input format or effects, leaving ambiguity.

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?

Clearly states the action (list), resource (Slack channels), and scope (connected workspace). Mentions free-text query and structural filters, distinguishing it from sibling tools that deal with broadcasts or audiences.

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 vs. alternatives, or when not to use it. Does not specify prerequisites or context where this tool would be preferable.

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 must carry the full burden. It only says 'list', which implies read-only, but misses behavioral traits like pagination, permissions, 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?

A single sentence that efficiently conveys the tool's purpose with no wasted 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 and a simple list operation, the description is adequate. No output schema exists, but it is not critical for a basic list 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?

The tool has zero parameters and 100% schema coverage, so no additional parameter explanation is needed. Baseline for 0 params is 4.

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 'list' and the resource 'sending profiles (sender identities)', and it is distinct from sibling tools like 'create_sending_profile'.

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 explicit guidance on when to use this tool versus alternatives, though the sibling context implies usage for viewing existing profiles. Lacks when-not or 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?

With no annotations, the description carries full burden. It indicates a non-destructive preview, but lacks details on required permissions, rate limits, or output format. Basic disclosure is present but incomplete.

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 sentence with no redundancy. Front-loads the action. Could be slightly more precise but 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 0% schema coverage, no output schema, and many sibling tools, the description is insufficient. It lacks usage guidelines, parameter explanations, and behavioral details.

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 description adds no meaning to the two parameters beyond the schema. Schema coverage is 0%, and the $ref in audience_id is unclear. Parameter roles are not explained.

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 'Render the per-audience Slack Block Kit array as it will be delivered', specifying a concrete action on a specific resource. It distinguishes itself from siblings like validate_broadcast or send_broadcast_now.

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 implies usage for previewing before sending, but provides no explicit when-to-use or when-not-to-use guidance, nor alternatives among the sibling tools.

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 provided, so description bears full burden. It only states what the tool does without disclosing side effects, constraints (e.g., must include all existing blocks), error behavior, or required permissions. This is insufficient for a mutation tool.

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?

Single sentence, 17 words, front-loaded with action. No unnecessary words or fluff. Efficient and well-structured.

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?

Tool is simple with 2 params and no output schema. Description covers purpose and parameter intent but lacks behavioral details like return values, error conditions, or prerequisites. Adequate but not fully complete given the complexity.

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 has 0% description coverage. Description adds meaning for 'block_ids' (full list in new order) but does not explain 'broadcast_id'. While broadcast_id is somewhat obvious, more detail would help. The description provides some added 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?

Description clearly specifies the action (reorder), the resource (blocks in a broadcast), and the method (providing full block-id list in new order). It distinguishes from siblings like add_block or set_block_visibility.

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 implies when to use the tool (to change block order) but does not explicitly state when not to use it or mention alternatives. The usage is clear but lacks 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?

No annotations provided, so description carries full burden. It mentions the requirement of an Idempotency-Key, which is a behavioral requirement. However, it does not disclose other behavioral traits like state changes, rescheduling capability, or error handling.

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 sentence, 13 words, front-loaded with the main action and then a key requirement. No wasted 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 4 parameters, 0% schema coverage, and no output schema, the description covers the core but lacks details on return values, prerequisites, error conditions, and timezone format requirements.

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 description must compensate. It mentions 'ISO timestamp + timezone' for send_at and timezone parameters, and 'Idempotency-Key' for idempotency_key. However, it does not explain broadcast_id or provide format details for timezone.

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 schedules a broadcast to send at a given ISO timestamp with timezone. It distinguishes from siblings like 'send_broadcast_now' which sends immediately.

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 explicit guidance on when to use vs alternatives. It does not mention prerequisites (e.g., broadcast must be in draft state) or 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?

Discloses key behaviors: idempotency requirement, conflict handling (409), schedule cancellation via confirm. Does not mention success response or authorization, but covers main operational traits for a mutation tool.

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?

Four concise sentences with front-loaded purpose. No verbose or redundant information; each sentence 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 key scenarios (immediate send, conflict, retry with confirm). Lacks success response details and additional error codes, but adequate for a 3-param tool with no output schema.

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?

With 0% schema coverage, description adds meaning for confirm (cancel schedule) and idempotency_key (required). Broadcast_id is implied but not described explicitly. Partially compensates for low 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?

Clearly states verb 'Send' and resource 'broadcast' with immediate execution. Differentiates from siblings like schedule_broadcast by handling scheduled broadcasts and requiring idempotency.

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?

Explicitly describes when to use (send now), conflict behavior (409 with pending time), and retry with confirm. Warns against pre-emptive use of confirm, providing clear when-not 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?

No annotations are present, so the description must handle transparency. It discloses the empty array behavior (visible to all), which is valuable, but omits other critical behaviors like whether the call overwrites previous visibility settings, requires specific permissions, or has side effects on existing blocks.

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 a clarifying clause, perfectly front-loaded. Every word earns its place, no redundancy or 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?

Given the tool has 3 required parameters and no output schema or annotations, the description is too brief. It lacks details on whether visibility settings are incremental, how to revert to default, or what happens on repeated calls. More context is needed for a mutation tool like this.

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 'audience_ids' (empty array = visible to all), but does not explain 'broadcast_id' or 'block_id'. The description provides partial semantic guidance but not enough to fully understand the parameters.

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 the specific verb 'restrict' and resource 'block's visibility', clearly stating the action and scope (subset of broadcast's target audiences). It distinguishes the tool from siblings like 'add_block' or 'set_broadcast_content', which deal with different aspects of broadcast creation. The empty array behavior is explicitly clarified.

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 implies usage for restricting visibility but does not explicitly state when to use this tool versus alternatives like 'add_block' or any other visibility-related tool among siblings. No exclusions or scenarios 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool replaces content (destructive) and returns blocks, but it does not address prerequisites (e.g., broadcast must exist, be in draft state), side effects, permissions, or error conditions. The behavioral detail is minimal.

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 consists of two sentences: the first states the primary action with key alternatives, and the second notes the return value. No unnecessary information. Front-loaded with the core purpose.

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 tool's complexity (two modes: markdown and segments), 0% schema coverage, no output schema, and no annotations, the description provides an adequate overview of functionality. However, it lacks detail on parameters (especially audience_ids) and prerequisites, making it minimally complete for an agent to fully understand invocation requirements.

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 to parameters. It explains that 'markdown' and 'segments' are alternative ways to provide content, and that 'segments' are targeted at audiences. However, it does not describe the 'broadcast_id' parameter or the 'audience_ids' within segments. Partial but helpful 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 explicitly states the verb 'Compose (or replace)' and the resource 'a broadcast's entire content', which clearly distinguishes it from sibling tools like add_block that operate on individual blocks. The mention of 'entire content' confirms it sets the full content rather than appending.

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 implies usage is for setting a broadcast's content from Markdown, but it does not explicitly contrast with alternatives like add_block or mention when not to use it (e.g., if content already exists and only needs partial changes). No when-to-use or when-not-to-use guidance is 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?

The description discloses full behavioral traits: it replaces the entire one-time group, empty list deletes it, and unjoined channels produce warnings with failed sends. No annotations exist, so the description carries the burden and does so thoroughly.

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 concise sentences, each adding essential information: purpose, replacement/deletion behavior, and warning behavior. No unnecessary words; front-loaded with the primary action.

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 two-parameter tool with no output schema, the description covers all critical aspects: purpose, usage constraints (draft-only), behavioral details (replaces, deletes), and side effects (warnings). The agent can correctly select and invoke the tool without ambiguity.

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?

Despite 0% schema coverage, the description adds rich semantic context: it explains channel_ids as an ad-hoc set, the replacement behavior, and the special case of empty list deleting the group. broadcast_id is implied as the draft broadcast. This far exceeds the baseline requirement.

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 targets a draft broadcast at an ad-hoc set of channels, distinguishing it from creating a saved audience or other broadcast operations. It specifies 'Draft-only', which differentiates it from send-related siblings.

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 indicates when to use (for draft broadcasts, one-time channel targeting) and that it replaces the whole group each call. It lacks explicit exclusions or alternatives, but the context is clear enough for an AI to infer proper usage.

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 provided. The description mentions 'heuristic' implying non-deterministic behavior, but does not disclose safety, failure modes, or boundaries.

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?

Single sentence with no unnecessary words; perfectly 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?

No output schema exists, so description should hint at output format. It does not explain what the suggestion result looks like, leaving some 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?

There are zero parameters, so the schema covers 100%. The description adds no parameter information beyond the schema, but baseline for zero parameters is 4.

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 suggests audiences heuristically based on channel-name patterns, using a specific verb and resource, and distinguishes from sibling tools like list_audiences and create_audience.

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 lacks explicit guidance on when to use this tool versus alternatives like list_audiences or create_audience, but it is not misleading.

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 provided; description does not disclose side effects, return format, or error behavior. The word 'Check' suggests read-only but doesn't confirm lack of mutation.

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?

Single sentence, no fluff, efficient. However, slightly too terse; could add context without becoming verbose.

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 validation tool with 1 param and no output schema, the description lacks return value details, error conditions, and behavioral context. Incomplete for agent invocation.

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 description adds no meaning beyond the input schema; it does not explain the singular parameter broadcast_id. Schema description coverage is 0%.

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 checks for channel-overlap conflicts in broadcasts, with a specific use case. It distinguishes from siblings like preview_broadcast or create_broadcast by focusing on validation.

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 vs alternatives, no prerequisites or order of operations mentioned. The description only implies validation before sending but doesn't make it explicit.

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