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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the write/destructive profile is covered structurally. The description adds useful scoping behavior (channel-tabbed vs. standalone canvas), but says nothing about permissions, whether standalone canvases are shared, or the result of the 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 short sentences, front-loaded with the action, and the branching rule for channel_id is stated compactly with no filler.

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 creation tool with no output schema, the description covers the core action and the key branching parameter, but leaves title undocumented and gives no hint of what is returned or where the new canvas can be found.

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 carry the load, and it does explain channel_id meaningfully and implies markdown_content. However, the title parameter is never mentioned, leaving one of three parameters undocumented anywhere.

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 ('Create a canvas from markdown') and immediately distinguishes the two modes via the channel_id sentence. It does not name siblings like canvas_edit, but the create vs. edit distinction is unambiguous from the verb.

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 explains the effect of channel_id vs. omitting it, which is runtime behavior rather than when-to-use guidance. There is no stated condition for choosing this tool over canvas_edit or any prerequisite/permission context.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description goes further by disclosing the blast radius of specific operations — notably that replace without section_id overwrites the entire canvas — which is exactly the kind of consequence detail annotations cannot express.

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?

Front-loads 'Apply one edit' then packs operation semantics into two dense sentences with no filler. The run-on operation list is information-rich but slightly hard to scan as a single block.

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 4-parameter mutation tool with no output schema, the description covers the operation vocabulary, the conditional requirements on section_id, and the destructive scope of a full-canvas replace — enough for an agent to invoke it correctly on the first try.

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 carry parameter meaning, and it largely does: it enumerates all seven operation values, explains when section_id is mandatory, and clarifies that markdown_content doubles as the new title for rename. It leaves insert_at_start/insert_at_end's payload requirement unstated, and canvas_id undefined.

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 ('apply one edit') and enumerates the exact operation set, so an agent immediately knows this is the single mutation entry point for canvas content. The resource is only implied through the tool name rather than the description text, and no sibling is contrasted, keeping it just 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?

Gives per-operation conditions: insert_before/insert_after/delete require section_id, replace without section_id replaces the whole canvas, rename repurposes markdown_content. It also routes the agent to canvas_find_sections to obtain section_id. It stops short of stating when to reach for canvas_edit versus canvas_create.

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 safety profile is already covered. The description adds one genuinely useful behavioral fact beyond the annotations - that the result is section IDs rather than content - but omits matching semantics (case sensitivity, substring vs exact) and how text and type filters combine.

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 front-loaded sentence with no wasted clauses; the criteria come before the example enumeration. The trailing '...' list of types is slightly loose but earns its place by hinting at the accepted enum values.

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 3-parameter read tool whose annotations cover safety, the description is close to sufficient, but it leaves the matching semantics of contains_text and the combination rule between text and type undefined, which an agent needs to call 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?

Schema coverage is 0%, so the description carries the burden. It compensates partly by enumerating plausible section_types values (h1, h2, h3, any_header, list, table), which the bare 'array of strings' schema does not, but contains_text matching rules and the canvas_id parameter are left 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 names a specific verb (find), resource (section IDs in a canvas), and the filter criteria (text and/or type). It clearly distinguishes the tool from write-oriented siblings like canvas_edit and canvas_create, though it never names an alternative explicitly.

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?

Usage is only implied by the phrase 'in a canvas by text and/or type'. There is no statement of when to prefer this over canvas_read, no prerequisites, and no note about whether results can be fed into canvas_edit.

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 safe, non-mutating nature is covered. The description adds that the return surface is the canvas's title and text content, which is useful since no output schema exists, but it says nothing about pagination, permissions, or behavior for missing/invalid canvases.

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 text is short with no waste, but it is an under-specified sentence fragment rather than a front-loaded action statement. Brevity here comes at the cost of clarity, not from tight editing.

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 low-complexity, single-parameter read tool with readOnlyHint annotations and no output schema, the description nearly suffices by naming the returned content. It still omits any routing versus sibling canvas tools and leaves the parameter undocumented, so a gap remains.

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% for the single parameter canvas_id, so the description carries the burden and fails to compensate. It conveys only that a canvas is involved, without explaining the ID format, where to obtain it, or error behavior for a bad 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 states the resource (a canvas) and what content is exposed (title and text), which implies a read operation. However, it is a noun phrase with no verb ('A canvas's title and text content'), so the action is only inferred, and it makes no attempt to distinguish itself from sibling reads like canvas_find_sections or canvas_edit.

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 when-to-use guidance, no prerequisites, and no mention of alternative tools such as canvas_find_sections for locating sections. The agent must guess the appropriate context for calling this 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond annotations: the CSV output format, the comma-separated multi-value semantics of channel_types, and the case-insensitive substring matching for query. However, it omits pagination behavior despite a cursor parameter existing.

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 compact, front-loaded fragments with no filler; the output format and key parameter semantics come first. It is dense and terse rather than verbose, though the fragment style is slightly cryptic.

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?

An output schema exists, so return values need no explanation. For a 6-parameter read tool, the description covers the required field and filtering/sorting well but is silent on pagination (cursor) and result limits, leaving a modest 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?

With 0% schema description coverage, the description must carry parameter meaning, and it does explain channel_types, query, query_targets, and sort semantics. It leaves limit and cursor entirely undocumented, so it only partially compensates for the coverage gap.

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 the resource (workspace channels) and the output form (CSV), making the operation recognizable as a list/query tool. It distinguishes itself implicitly from channels_me (singular) and conversations_history (message history) by scoping to channel enumeration with filtering, though the verb itself is only implied.

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 when-to-use guidance or routing to alternatives such as channels_me, conversations_search_messages, or conversations_history, all of which appear in the sibling set. The agent must infer selection conditions without help.

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 safety is covered. The description adds the useful output-format fact (CSV), but says nothing about pagination behavior despite cursor and limit parameters, nor what the CSV contains column-wise.

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 terse sentences, no waste, and the resource scope is front-loaded. The brevity is under-specification rather than padding, but the dimension is about structure and economy, which it does well.

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?

An output schema exists so return values need no explanation, but for a 3-parameter paginated list tool the description omits anything about cursor/limit usage or pagination. An agent could invoke it without knowing it is paginated at 100 per page.

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 carries the burden and largely fails: limit and cursor are undocumented anywhere, and channel_types is only explained by deferring to another tool's semantics ('as in channels_list'), forcing a lookup.

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 resource with a clear scope qualifier: 'conversations you are a member of', which distinguishes it from the broader channels_list. The verb is only implied (list) but the noun and scope make the 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 membership scoping implies when to use it versus channels_list, but no explicit when/when-not guidance or alternative routing is given. The agent must infer the distinction from the scope phrase alone.

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=false and destructiveHint=true, so the write nature is covered. The description adds genuinely useful behaviour beyond that: content_type rendering modes, the fact that blocks take precedence over text, that text degrades to a notification fallback, and that link/media unfurling is disabled. It stops short of explaining irreversibility or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler, and the core action is front-loaded before the formatting caveats. The clipped, note-like phrasing ('POST a message as you. content_type: ...') is dense but readable and appropriate for the length.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, for a 5-parameter mutation tool with 0% schema coverage, the absence of any thread_ts guidance and any when-to-use routing leaves the definition only minimally 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 the description must compensate, and it only partly does. It explains content_type, blocks, and text semantics well, but channel_id and thread_ts — including how threading changes the call — are entirely undocumented in both schema and 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 opens with a specific verb and resource: 'Post a message as you,' naming the acting identity, which is a meaningful distinction in a Slack toolset. It is clearly different from read siblings like conversations_history or conversations_replies, though it never explicitly contrasts itself with schedule_message, the closest functional neighbour.

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 statement of when to use this tool versus alternatives such as schedule_message, canvas_edit, or list_item_create, and no prerequisites (channel membership, posting permissions) are given. The only implicit guidance is the blocks-vs-text precedence rule, which is formatting behaviour rather than usage 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?

readOnlyHint=true already establishes this is a safe read. Beyond that the description adds real behavioral context: CSV output, newest-first ordering, the local-midnight basis for window limits, and the rule that passing the cursor preserves the original window and page size. It does not mention permissions 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?

Three compact sentences, front-loaded with what the tool returns before moving to parameter mechanics. Dense but every clause carries usable information; no filler.

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?

An output schema exists, so return values need not be enumerated, and the read-only annotation covers the safety profile. The description still supplies the pagination and window semantics an agent needs to call it correctly; only include_activity_messages is left unaddressed.

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 carries the load, and it does so well for the two non-obvious parameters: limit's dual count/window syntax with examples ('50', '1d', '2w', '3m') and the cursor round-trip contract. channel_id is self-evident, but include_activity_messages is never mentioned, leaving one of four parameters undocumented.

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 resource and scope: messages in a channel or DM, returned as CSV, newest first. That scope implicitly separates it from conversations_replies (threads) and conversations_search_messages, but no sibling is named explicitly, so it stops 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 gives concrete operational guidance: limit accepts either a count or a window and should be left empty when a cursor is passed, and it explains when to paginate (non-empty Cursor column on the last row). It does not say when to prefer this tool over conversations_search_messages or conversations_replies, so it lacks explicit 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=true already establishes the safety profile, so the description's main additions are the CSV output format and the thread_ts identifier format with an example. It says nothing about ordering, completeness of the reply set, or why include_activity_messages exists, so behavioral context beyond annotations is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with the output format front-loaded and no filler. The cross-reference for limit/cursor is compact, though '1d' default on limit goes unexplained and slightly undercuts the terseness.

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?

An output schema exists, so return values need no explanation, and annotations cover safety. However, with a required channel_id and a non-obvious include_activity_messages flag documented nowhere, the description is not complete enough for confident 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?

Schema coverage is 0% across 5 parameters, so the description must carry the load. It usefully defines thread_ts with an example and points to conversations_history for limit/cursor, but channel_id (required) and include_activity_messages are entirely unaddressed, leaving a meaningful gap.

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 the resource and shape of the result clearly ('A thread (parent plus replies) as CSV'), which distinguishes it from the channel-wide conversations_history. It lacks an explicit verb, but the operation (retrieve a thread) 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 defers to conversations_history for limit/cursor semantics, implying the same paging model, but never states when to pick this tool over conversations_history, conversations_search_messages, or conversations_add_message. Usage is only inferable from the tool name and the 'thread' framing.

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 readOnlyHint=true already covering the safety profile, the description goes beyond annotations by disclosing search operator syntax, the special message-URL behavior, the accepted date formats and their during-vs-other semantics, the limit range, and notably the cursor rule that filters supplied with a cursor are ignored. That cursor caveat is genuinely non-obvious behavior an agent would otherwise get wrong.

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?

Dense, telegraphic and front-loaded: the core verb comes first, then input syntax, then paging rules. Every clause carries information, though the date-format sentence is cramped and requires careful parsing.

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 12-parameter tool with zero schema documentation, the description covers most of what is needed to call it correctly, and the existence of an output schema means return values need not be described. The gaps are the two unexplained filter parameters and the absence of sibling routing guidance.

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 12 parameters, so the description carries the full burden. It supplies value formats for search_query, user filters (ID, @handle, name), channel filters (ID or #name), the date filter family, limit, and cursor. It does not explain filter_threads_only or filter_in_im_or_mpim, leaving two parameters undocumented anywhere.

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 and resource ('Search messages') and even names the output form (CSV). It does not distinguish itself from close siblings like conversations_history or conversations_replies, so an agent gets no explicit routing signal, but the purpose itself 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 implicitly tells the agent how to use the tool by explaining that search_query takes Slack modifiers or a full message URL (which then returns that single message), which is a quasi-usage signal. However, there is no explicit when-to-use / when-not-to-use guidance and no mention of the sibling tools that overlap (conversations_history, conversations_replies).

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 destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds the temporal constraint 'before it posts', which is genuinely useful context, but says nothing about auth requirements, error behavior, or what happens after the post time.

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 tight sentence, front-loaded with the verb and resource. 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?

Annotations carry the safety profile and the description carries the temporal constraint, but with two undocumented required parameters and no output schema, an agent still lacks the id format and failure-mode information needed for reliable 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?

Schema description coverage is 0%, so the description must compensate for both parameters but provides nothing about channel or scheduled_message_id formats. With two required parameters entirely undocumented, the description fails to fill the gap.

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?

Clear verb (Cancel) plus resource (scheduled message), and distinguishes itself from schedule_message by its cancel semantics. It doesn't explicitly name the sibling alternative, but the intent 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives like list_scheduled_messages for finding the id first. The agent is left to infer usage from the name alone.

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=false and destructiveHint=true, so the safety profile is partially covered. However, the description is silent on the mutation semantics: it does not say what gets created or returned, whether permissions/scopes are required, or what todo_mode changes. It only restates the schema parameter shape.

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 short, front-loaded statements with no filler. The embedded schema literal is dense and slightly malformed (e.g. '"is_primary_column"?'), which costs a little clarity but keeps the entry brief.

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 creation tool with three parameters, no output schema, and 0% schema coverage, the description omits the todo_mode semantics, the return value (e.g. new list ID), and any permission requirements. It is not sufficient to call the tool confidently beyond the trivial 'name' argument.

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% for three parameters, so the description carries the full burden. It partially documents only the 'schema' parameter's intended format and says nothing about 'todo_mode' (behaviorally significant) or constraints on 'name'.

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 clear verb+resource: 'Create a Slack List'. That distinguishes it from read-oriented siblings like list_items, but it does not differentiate from the closely named list_item_create, which an agent could easily confuse with it.

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 about when to use this tool versus the sibling list tools (list_items, list_item_create, list_items_update), no prerequisites, and no conditions selecting one over another. The agent must infer usage entirely from the name.

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=false and destructiveHint=true, so the write/destructive nature is covered structurally. The description adds useful detail about the initial_fields payload shape, but says nothing about permissions, side effects, or what happens on conflict. With annotations covering the safety profile, a 3 is appropriate.

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?

Very short and front-loaded with the core action before the format detail. Nothing is wasted, though the terse bracket syntax is slightly cryptic without more context.

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 mutation tool with no output schema and 3 parameters, the description covers the initial_fields format but leaves list_id and parent_item_id (the required and optional relationship param) unexplained. Adequate but with 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 coverage is 0%, so the description must carry the burden. It does explain the initial_fields structure ('{"column_id", <type>: value}' and rich_text blocks for text columns), which is genuinely helpful, but list_id and parent_item_id receive no explanation at all.

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 and resource ('Add an item'), so the agent knows this creates a list item. It does not explicitly distinguish itself from siblings like list_items_update or list_create, but the name and phrasing make the scope clear enough.

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 list_items_update or list_create, nor any prerequisites. The description jumps straight into field formatting with no usage context.

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 safety is covered. The description adds real context beyond that by explaining that include_list also returns columns and that column_id matters for writes, but it says nothing about pagination behavior despite limit/cursor existing.

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?

It is a single short sentence with no waste, but it is a noun fragment rather than a front-loaded statement of what the tool does, and the terse phrasing leans on punctuation to carry two ideas.

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 4-parameter tool with 0% schema description coverage and no output schema, the description omits pagination (limit/cursor) semantics and the required list_id, leaving the agent without enough to call 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?

Schema description coverage is 0%, so the schema provides no parameter documentation. The description only addresses include_list (and its column_id consequence) while leaving limit, cursor, and list_id entirely unexplained, so it fails to compensate for the coverage gap.

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 the resource ('A List's items') but never states a verb, so it's unclear whether this retrieves, lists, or returns the objects. It offers a partial hint that it is a read that can also surface columns, but an agent cannot confidently distinguish its purpose from siblings like list_create or list_items_update without inference.

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 when-to-use guidance or named alternative. The trailing note that column_id values are needed 'for writes' faintly implies this is a prerequisite read before write operations, but no condition or exclusion is 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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation risk is covered. The description adds a useful behavioral detail (the 100-cell cap), but says nothing about what happens on overflow, whether the batch is atomic on failure, or what a partial update does to existing values.

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?

It is a single compact line with the operation front-loaded and the payload example inline. Nothing is wasted, though it is arguably under-specified rather than lean.

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 destructive mutation with no output schema and zero schema-description coverage, the description omits return behavior, failure semantics, and the meaning of list_id. The 100-cell limit is the only substantive behavioral fact provided.

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 schema alone documents nothing. The description compensates for the cells parameter by giving its element shape (row_id, column_id, <type>: value), but list_id is entirely unexplained and the accepted value types remain unspecified.

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 gives a verb ("Update") and a scale limit ("up to 100 cells") and shows the expected payload shape, so the operation is broadly inferable. However, "cells" is never tied to list items, and there is no differentiation from siblings like list_item_create or list_items, leaving an agent to guess how this differs.

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 when-to-use guidance, no prerequisites, and no named alternative. The description neither explains when this bulk-update path should be chosen over single-item operations nor states any exclusion, so the agent has no routing signal.

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=true already tells the agent this is a safe read. The word 'pending' adds one useful behavioral fact (only unsent messages are returned), but the description is silent on pagination despite a cursor parameter, and says nothing about result size 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 front-loaded sentence with no filler, which is good, but the brevity comes at the cost of under-specification for a two-parameter paginated tool. It is terse rather than genuinely economical.

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 no output schema, no annotations beyond readOnlyHint, and 0% schema description coverage, the description carries most of the burden and does not deliver: return shape, pagination behavior, and cursor usage are all missing.

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 there are two parameters. The description covers only 'channel' (as an optional filter) and gives no format or ID semantics for it; 'cursor' is completely undocumented in both the schema and the description, leaving pagination 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 noun phrase identifies the resource and scope ('your pending scheduled messages'), which lets an agent separate it from schedule_message and delete_scheduled_message. However, it lacks an explicit verb (list/retrieve) and never contrasts itself with the sibling tools, so the purpose is only implied rather than stated.

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?

'optionally for one channel' hints at one usage mode but gives no when-to-use context, no prerequisites, and no routing against alternatives like delete_scheduled_message or schedule_message. An agent must infer that this is the read counterpart to those 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, telling the agent this is a non-destructive write. The description adds the emoji-format rule (name without colons), which is useful, but says nothing about idempotency (adding the same reaction twice), permission requirements, or failure modes.

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 well-formed sentence with the action front-loaded and no filler. It is efficient, though the brevity comes at the cost of the missing guidance noted elsewhere.

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?

An output schema exists so return values need not be described. However, for a three-parameter mutation tool with zero schema descriptions, the definition should at least identify what channel_id and timestamp refer to; as written it covers only the emoji parameter.

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 all three parameters are required but undocumented in the schema. The description clarifies only the emoji format; channel_id and timestamp are left entirely unexplained, so it does not compensate for the coverage gap.

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 (add) and resource (emoji reaction to a message), so the agent knows exactly what the tool does. It doesn't explicitly name reactions_remove as the counterpart, so it falls short of full sibling differentiation, 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?

There is no guidance on when to use this versus alternatives such as reactions_remove, nor any prerequisites (channel membership, existing message, duplicate reactions). Usage must be inferred entirely from the tool name.

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=false and destructiveHint=true. The description adds the scope that only the user's own reaction is removed, which is useful behavioral context, but it does not describe authentication needs, idempotency, or side effects.

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 front-loaded sentence with zero filler. Every word contributes to the action and scope.

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 operation with annotations and an output schema, the description conveys the core action and scope. However, it is incomplete for the three parameters, whose meanings are left entirely to the schema despite 0% description coverage.

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 three required parameters. The description does not explain what channel_id, timestamp, or emoji should contain or how they relate to the removal operation, failing to compensate for the schema's lack of parameter 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 states a specific verb (Remove) and resource (your emoji reaction from a message). It clearly distinguishes the action from its sibling reactions_add, which performs the opposite operation.

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's usage—undoing your own reaction on a message—but does not explicitly state when to use it versus alternatives or any prerequisites. It is minimum viable but leaves the agent to infer context.

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=false and destructiveHint=true, so the write/side-effect profile is covered structurally. The description adds the 120-day scheduling limit, which is useful context, but it does not explain the odd 'destructive' classification, required channel/text content, per-channel permission needs, or what identifier is returned for later cancellation.

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 short sentences, zero filler, with the action and its hard constraint front-loaded before the format hint. Nothing repeats the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter mutation with no output schema and no annotation nuance, this is thin: it omits thread reply behavior, channel targeting semantics, and what a successful call yields so the message can be found or cancelled later. The post_at clarification is the one substantive addition.

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% for four parameters, so the description must carry the load and it only partially does: post_at is genuinely clarified ('Unix seconds or ISO-8601 with offset'), which the bare string schema does not convey. channel, text, and especially thread_ts remain undocumented (e.g., whether channel accepts an ID or name, what a thread_ts value is).

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?

Specific verb + resource ('Schedule a message') with a stated horizon constraint (up to 120 days ahead), so the action is unambiguous. It does not differentiate from the closest siblings, conversations_add_message (send now) and list_scheduled_messages / delete_scheduled_message, which an agent must choose between.

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 when-to-use or when-not-to-use guidance is given. The description never mentions that this is the delayed counterpart to conversations_add_message, nor that scheduled messages are later managed via list_scheduled_messages / delete_scheduled_message.

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=true already establishes this as a safe read, so the bar is lower. The description adds real behavioral value by disclosing the CSV output format and the conditional inclusion of the users field, but says nothing about pagination, result size limits, or the meaning of include_disabled.

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 front-loaded sentence that lists the fields efficiently with zero filler. It is terse almost to a fault, but every clause carries information.

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 an output schema present, the return values need less explanation, yet include_disabled is never clarified and usage context is absent. Adequate for a simple read tool but with a clear gap around one parameter and the sibling distinction.

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 compensate. It explains include_users ('users (if include_users)') but leaves include_disabled completely undocumented, so only half the parameters gain meaning beyond their names.

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 resource (user groups) and clarifies them as '@mention groups', and mentions the CSV output shape. It does not differentiate from the sibling usergroups_me, so an agent must infer the distinction from the name alone.

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 when-to-use guidance, no prerequisites, and no reference to alternatives such as usergroups_me. The agent is left to infer that this is the enumeration counterpart to that 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds one useful behavioral detail beyond the annotations — the response is CSV formatted — which matters for how the result must be parsed. Beyond that it discloses nothing about scope, 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 fragment with zero filler, front-loading the resource type and the self-scope qualifier. Nothing to trim and nothing buried.

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?

An output schema exists, so the description need not describe the return value beyond flagging the CSV format, and there are no parameters to explain. The only mild gap is absence of any routing hint against usergroups_list, but the scope qualifier largely covers that.

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 takes zero parameters, so there is nothing to document; baseline for a no-param tool is 4. The description's 'as CSV' note is the only invocation-relevant detail and it is about output, not inputs.

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?

Names a specific resource (user groups) and scopes it to those the caller belongs to, which distinguishes it from the sibling usergroups_list. The verb is implicit (a retrieval) and the phrasing is a sentence fragment, but an agent can tell what it returns.

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 'you belong to' implies the selection condition (self-scoped) versus usergroups_list, but no alternative is named, no when-to-use or when-not-to-use is stated, and no prerequisites are given. Usage is inferable 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 only cover readOnlyHint=true; the description goes beyond them by disclosing case-insensitive substring matching, CSV output format, and that the DM channel ID is only populated when one exists. It stops short of stating result ordering, 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?

A single dense sentence with the core action front-loaded and no filler. The 'as CSV' clause is somewhat mid-sentence and slightly disrupts the matching-fields list, but nothing is wasted.

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?

Return structure is largely covered by the declared output schema, and the description adds the DM-channel conditional and case-insensitivity needed to interpret results. The undocumented 'limit' parameter is the one remaining gap against a 2-parameter read-only 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?

With 0% schema description coverage the description must compensate: it richly documents the 'query' parameter's accepted fields and matching mode, but says nothing about 'limit' (default 10, max cap, or its interaction with result size), leaving half the parameters undocumented in both places.

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 ('Find users') and enumerates the exact match surfaces (ID, handle, display name, real name, email). It is clearly separable from group-oriented siblings like usergroups_list/usergroups_me, though it never names an alternative explicitly.

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 use case (look up users when you only have partial identity info) and even clarifies matching semantics, but gives no when-not guidance, no prerequisites, and no routing to alternatives such as usergroups_list for group lookups.

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