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

With no annotations, the description carries the full behavioral burden and does add real value: it discloses that the return is a path on the bridge host and warns that view-once media lands in a temporary folder and is deleted soon ('never keep it'). It omits failure modes, permissions, and whether the download is cached, but the ephemeral-media warning is genuinely useful context.

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 the core action and return value, follows with the critical view-once warning, and closes with the Args block. Every element earns its place given the 0% schema coverage, though the format is slightly blocky rather than prose-tight.

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, yet the description still notes the returned path. Both parameters are documented and the ephemeral-media caveat covers the main behavioral risk for this tool, leaving only minor gaps like error handling.

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 does: message_id is explained as coming from the channel event and 'to' as a chat alias that may be omitted for the sole subscribed target. It adds meaning beyond a bare 'To'/'Message Id' title, though it does not specify format or ID shape in detail.

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 (download) and a precise resource (a message's photo, video or voice clip) and notes it returns a path on the bridge host, which clearly separates it from send_file/share_media/transcribe_share. It stops short of naming any sibling alternative, so it is clear but does not explicitly differentiate.

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 practical context: message_id comes from the channel event, and 'to' should be omitted for the sole subscribed target. However, there is no explicit when-to-use-vs-alternatives guidance (e.g. when to download_attachment versus transcribe_share or share_media), so usage is only 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?

No annotations are provided, so the description carries the burden; it discloses the output medium (plain text vs JSON), the size tradeoff, and the pagination behavior ('offset' skips the most recent messages). It does not cover permissions, prerequisites, or thread-not-found behavior, but for a read-only fetch these are minor omissions.

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-loaded with purpose and the key differentiator in the first two lines, then a compact Args list. The Returns block is partly redundant with the existing output schema, but it costs little and the whole description is short.

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 three-parameter read tool with an output schema present, the definition covers purpose, alternative, all parameter semantics, and result shape. Only behavioral edges like permission requirements or empty-thread behavior are absent, which is acceptable given the output schema handles return values.

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 does: thread_id is identified as the thread to pull messages from, amount is the max messages with its default, and offset's non-obvious semantics (skip the N most recent, not the first N) are spelled out.

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 ('Get conversation as a readable chat log') and immediately characterizes the output form (plain-text, ~5x smaller than JSON). It explicitly distinguishes itself from the sibling get_messages, which returns structured fields, so an agent can route without opening either schema.

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?

Names the alternative ('Use get_messages for structured fields') and gives the selecting condition (readable log optimized for LLM analysis, ~5x smaller). That is explicit when-to-use plus an alternative, leaving little to inference.

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 carry the behavioral burden, and it does disclose scope ('yours and the ones the owner sent from their phone') and ordering. However, it says nothing about read-only safety, pagination, or whether the listing is bounded beyond the limit default.

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-loaded purpose sentence followed by a scoping sentence and a tidy Args block; nothing is wasted. The middle sentence ('That is yours and the ones the owner sent from their phone') is slightly awkward but carries real scoping 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?

An output schema exists, so return-shape explanation is unnecessary, and the description supplies purpose, scope, ordering, and all parameter meanings. Only minor gaps remain, such as what window 'recent' covers.

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 documents all three parameters: 'to' as a chat alias with omission semantics, 'filter' as a text substring match, and 'limit' with its default of 10. That covers the schema gap well, though it adds no format examples for the alias.

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 ('List this account's recent messages with their ids'), the ordering ('newest first'), and a purpose hint ('for unsend') that separates it from the heavier get_messages sibling. It stops short of naming the alternative explicitly, so differentiation is 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?

The parenthetical '(for unsend)' signals the intended workflow, implying it should be called when you need message ids for a subsequent unsend, and the scope line clarifies which messages count. There is no explicit when-not guidance or named alternative against get_messages/get_chat_log.

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 does reveal meaningful behavior (offset skips the most recent messages, has_more signals pagination, seen_since and share appear conditionally), but it never says whether fetching marks messages read or what access is needed — an important omission given mark_read is a sibling.

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-loaded with the one-line purpose, then a clearly ordered Args block and a Returns block. Every line is relevant and there is no filler, though the Returns enumeration is somewhat long given an output schema already exists.

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 three-parameter read tool with an output schema, the core information is present. The gaps are behavioral and navigational: no side-effect disclosure (does reading mark messages seen?) and no routing versus sibling read tools, which matters in a 28-tool namespace.

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%, yet the description documents all three parameters with semantics beyond the schema: amount is a maximum, offset skips the N most recent (not oldest) messages, and thread_id identifies the source thread. This compensates well for the bare schema, though it doesn't state bounds for amount.

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: 'Get messages from a thread.' An agent knows exactly what it retrieves. However, it never distinguishes itself from close siblings like get_message_ids or get_chat_log, so the agent cannot tell from the description alone which of these to pick.

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 at all — no mention of when to prefer this over get_message_ids, get_chat_log, or search_threads, and no prerequisites or exclusions. The Args section documents inputs but gives no selection criteria.

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 the burden, but 'Get' reasonably conveys a non-mutating fetch and there are zero parameters, so little behavior needs disclosing. It says nothing about pagination, ordering, permissions, or rate limits, which keeps it at minimally viable.

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 purpose in the first sentence. The 'Returns' block is arguably redundant given an output schema exists, but it costs little.

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 return-value description is unnecessary duplication rather than a gap. For a zero-param read tool the definition is close to sufficient, but the absence of any guidance on how it differs from sibling thread listings leaves a real hole.

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 no parameters, so there is no argument semantics for the description to clarify. Baseline 4 applies.

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 with a scoping qualifier ('pending message request threads'), which implicitly separates it from list_threads/get_thread. However, it never names a sibling or explains what makes a thread 'pending', so the agent must infer the distinction.

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, when-not-to-use, or alternative routing guidance despite five closely related thread tools (list_threads, get_thread, search_threads, hide_thread). The scope word 'pending' is the only hint about 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?

With no annotations provided, the description carries the full behavioral burden, yet it only restates the return shape (which the output schema already covers). It never states that this is a read-only operation, whether messages are returned newest-first, whether 'amount' truncates the oldest or newest messages, or any auth/rate-limit considerations.

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 docstring-style layout is front-loaded with the one-line purpose, then Args and Returns. The Returns block largely duplicates the output schema, which is minor waste, but overall it is tight and readable.

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 two-parameter read tool with an output schema, the core essentials are present, and the return explanation is not strictly needed. However, the lack of any ordering/pagination semantics for 'amount' and the absence of usage context against sibling tools leave meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does document both parameters: thread_id ('ID of the thread to fetch') and amount ('Maximum number of messages to fetch (default: 20)'). It adds little beyond the names and default, but coverage of the two params is complete.

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 ('Get a specific thread with its messages'), which clearly separates it from list_threads and search_threads. It does not explicitly contrast with get_messages, which fetches messages alone, so the boundary with that sibling is left to 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?

The description says nothing about when to call this versus the many sibling alternatives (list_threads, search_threads, get_messages, get_chat_log) and gives no prerequisites or conditions. It is pure capability statement with no routing guidance.

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

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

Annotations already declare destructiveHint=true, so the destructive nature is covered by structured data. The description adds nothing beyond that – it doesn't clarify whether the thread is removed permanently, hidden only from inbox, or recoverable, which matters given the ambiguous 'Hide/delete' wording and an output schema that is never referenced.

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 action, though the awkward 'Args:' block restates the single parameter with no added value and the slash verb introduces ambiguity rather than structure.

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 needn't be explained, but for a destructive mutation with a crowded sibling set the description should distinguish hide from delete and from mute_thread. It leaves the key behavioral question (what actually happens to the thread) unanswered.

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 only description of thread_id is the tautological 'ID of the thread to hide.' No format, source, or expected value information is added beyond the schema's own field 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 verb+resource ('Hide/delete a thread from inbox'), so purpose is identifiable. However, it conflates two distinct operations (hide vs delete) with a slash, leaving ambiguity about actual effect, and does not differentiate from siblings like mute_thread or unmute_thread.

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 such as mute_thread (which hides notifications without removing) despite a crowded sibling set. The agent must infer when hiding is appropriate.

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 the full burden. The verb 'List' implies a read-only, side-effect-free operation and the output schema covers the return shape, but the description says nothing about scope (all subscriptions vs. a workspace), ordering, or pagination 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 front-loaded sentence with no filler. Every word earns its place and the resource is named immediately.

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 parameters, an output schema, and simple read semantics, the definition covers what an agent needs to invoke it. It misses only scoping and result-ordering context, which are minor for a no-arg lister.

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 for the description to disambiguate. Baseline 4 applies for a no-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (subscribed chats) plus the included field (aliases). It is clearly distinguishable from the write-side siblings subscribe/unsubscribe. It does not explicitly name a sibling or contrast itself with them, 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?

There is no statement of when to use this tool, no prerequisites, and no pointer to an alternative such as get_chat_log or search_threads. Usage is only inferable from the name. This is the definition's weakest dimension.

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 scopes the source ('inbox') but says nothing about ordering, pagination beyond the amount cap, read/unread filtering, or permissions. It restates the return shape, which is already covered by the output 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 purpose is front-loaded in one sentence, followed by clearly labeled Args and Returns sections. It is appropriately sized, though the Returns block partly duplicates the existing output schema.

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 output schema already covers return values, so the Returns block is redundant, and the definition omits the usage guidance an agent needs to route between the many thread-related siblings. It is minimally adequate but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It fully documents the single parameter - 'amount: Maximum number of threads to fetch (default: 20)' - giving both meaning and default where the schema provides neither.

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 ('Get') and resource ('direct message threads') with a clear scope ('from inbox'), so an agent can tell it lists threads. It does not, however, distinguish itself from siblings like search_threads, get_pending_threads, or get_thread, leaving the boundary implicit.

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 search_threads, get_pending_threads, or get_thread, all of which also surface threads. No prerequisites or exclusions are offered, so the agent must 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?

With no annotations, the description carries the full burden. It does disclose a useful behavioral trait — only the newest entry in message_ids is used, so extra ids are redundant — and that `to` defaults to the single subscribed target. It does not say what happens on failure, whether marking is idempotent, or any auth/subscription prerequisites.

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?

Purpose is front-loaded in the first sentence, followed by a compact per-argument breakdown. Given 0% schema coverage the parameter notes earn their place rather than being redundant, though the 'Args:' formatting restates schema key names.

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. As an unannotated mutation tool the description covers the essential call semantics but omits permissions, error conditions, and what 'read' state changes for the target chat, leaving a moderate gap for a tool that alters shared state.

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 does: it explains message_ids is sourced from channel events and only the newest is honored, and that `to` is a chat alias omittable when there is one subscribed target. This adds real meaning beyond the bare schema types.

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 action (mark messages read / emit a 'Seen' receipt) with clear scope: 'up to the newest of these messages'. An agent can distinguish it from sibling mark_thread_unread and from read tools like get_messages. It stops short of explicitly naming an alternative, so it is clear but not sibling-differentiating.

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 word 'Optional' signals this is not required for normal message flow, and 'Omit for the sole subscribed target' guides the `to` parameter. However there is no explicit when-to-use/when-not-to-use framing or reference to alternatives such as mark_thread_unread, so usage is only 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?

No annotations are provided, so the description carries the full behavioral burden. It states the state change but says nothing about persistence, permission/auth requirements, effects on other participants, or behavior when the thread is already unread, which are the relevant traits for a mutation tool with zero annotation coverage.

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 core sentence is front-loaded and there is no filler prose. The 'Args:' docstring block is slightly redundant boilerplate for a one-parameter tool, but it is brief rather than bloated.

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 the single parameter is covered. What is missing is any behavioral context (auth, idempotency, effect scope), leaving a mutation tool only minimally described.

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%, but the description documents the only parameter ('ID of the thread to mark unread'), so all parameters are accounted for. It adds little beyond the schema title, but with a single required param the compensation is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Mark a thread as unread'), which is unambiguous on its own. However, it never references the sibling tool mark_read, which is the direct inverse, so the agent gets no help disambiguating the pair from the text 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 or when-not-to-use guidance, no mention of prerequisites, and no pointer to mark_read as the alternative. Usage is only implied by the tool name itself, which is the bare minimum.

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 the full burden. It doesn't state whether muting is idempotent, what permission or membership it requires, whether it affects only push notifications or also unread counts, or how to reverse it. 'Mute notifications' alone is thin for a state-changing 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 core sentence is front-loaded and there is no filler. The 'Args:' block is redundant formatting given the schema already declares the parameter, but it costs little.

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

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

For a simple one-parameter tool with an output schema present, the description covers the minimum. It still omits reversibility, permissions, and scope of the mute, which a mutating tool ideally discloses when annotations are absent.

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, so the description must compensate. It names thread_id and clarifies it is the thread to mute, but adds no format, type, or lookup guidance beyond the schema's own property 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 specific verb and resource ('Mute notifications for a thread'), which is clear and atomic. It implicitly contrasts with the sibling unmute_thread but never names it explicitly, so differentiation is left to 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 when-to-use guidance, no mention of prerequisites, and no reference to the obvious alternative (unmute_thread) despite it being a sibling. The agent must infer that this is the inverse of unmute_thread.

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 the full behavioral burden. It discloses the essential side effect (the share is downloaded) and describes the return shape (caption, photos, per-video file/length/preview composed of 6 frames). It omits permission requirements, whether the download persists, and whether the operation mutates message state, which keeps it short of a 5.

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?

Purpose and primary usage guidance are front-loaded, and the paragraph structure separates the action, the return value, the follow-up inspection recipe, and the alternative tool. The embedded ffmpeg commands are verbose but operationally useful rather than filler, so only a minor deduction for density.

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, yet the description still helpfully characterizes the return (caption, photos, per-video file and preview), so nothing essential is missing for invocation. Residual gaps are unstated permissions/authentication and whether re-opening re-downloads, but the definition is otherwise complete for this complexity level.

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 does: message_id is defined as 'Message id of the share, from the channel event' and 'to' as 'Chat alias. Omit for the sole subscribed target.' Both parameters gain meaning beyond the bare schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Open a shared reel, post or story: download it and see what's in it') and clarifies the downstream effect (downloading the media). It differentiates from siblings by naming transcribe_share as the tool for audio content, so an agent can route correctly without opening schemas.

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?

Explicit guidance is given on how to use the output ('Read the preview first'), how to inspect media further ('pull frames yourself' with exact ffmpeg commands), and when to switch tools ('For what is said, call transcribe_share'). This covers when-to-use and the alternative, which is exactly the bar for a 5.

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 the full burden. It does disclose an important behavior — empty emoji removes your existing reaction — and the default behavior of 'to' (sole subscribed target), but stays silent on permission requirements, error cases, and whether reactions are idempotent.

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 the core action in one sentence, then a compact Args list. Every line carries information; only the arg labels restate parameter names, which is acceptable in this format.

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 mutation tool with an output schema available, the description covers all parameters and the key behavioral nuance (reaction removal). It is essentially complete, missing only auth/error context that annotations would normally supply.

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 and largely does: it documents message_id's source (channel event or get_message_ids), emoji format with a concrete example and the empty-string removal case, and 'to' as the chat alias with default omission behavior.

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 (react to a message with an emoji) and clarifies the dual add/remove semantics. It is clearly distinct from siblings like reply, send_typing, or mark_read, though it does not name an alternative outright.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage is clear — react to an existing message id — and the note that an empty emoji removes your reaction is a useful usage rule. However there is no explicit when-to-use versus alternatives (e.g. reply), nor any stated prerequisite that a subscription/target must exist.

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 the full burden. It usefully discloses the default-target behavior when `to` is omitted, but says nothing about what happens with multiple subscribed targets, delivery semantics, or failure modes for a send 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?

Front-loaded with the one-line purpose followed by a compact args block; every line earns its place. Minor redundancy with the schema's own field names, but no padding.

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 the addressing model is covered. However, the description introduces the 'sole target' concept without saying what occurs when the target is not sole, which is the key ambiguity an agent would hit.

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, and it does for the non-obvious parameter: `to` is explained as a chat alias with an example and a default/omit semantic. `text` is only restated as 'Message text', which is trivial but leaves no real 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?

States a specific verb and resource ('Send a text message'), which implicitly separates it from send_file/send_audio/send_typing among the siblings. It does not name a sibling explicitly, but the 'text message' scope 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?

The addressing rule ('Address by alias via `to`, or omit it for the sole target') gives real conditional guidance for how to call it, but there is no statement of when to prefer this tool over send_file/send_audio, nor any exclusion or prerequisite. Usage is implied rather than spelled out.

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 the full behavioral burden. It discloses the return shape but says nothing about read-only nature, permissions, rate limits, result limits, or pagination for a tool that clearly queries a large dataset.

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 prose is tight and front-loaded with the core purpose. The Args/Returns scaffolding is somewhat wasteful since an output schema already exists, but nothing is sprawling.

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

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

For a single-parameter read tool with an output schema, the definition covers the essentials; the return-value explanation is redundant with the schema. What is missing is routing guidance relative to list_threads and any behavioral constraints, leaving it 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 coverage is 0%, so the description must compensate, and it does clarify that the single required "query" param is a username or thread title. That is meaningful added value, but it stops short of matching behavior (exact vs partial, case sensitivity).

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 ("Search") and resource ("threads") plus the matching criteria (username or thread title), so the agent knows exactly what the tool does. It does not, however, distinguish itself from the sibling list_threads, leaving a small ambiguity about which to pick.

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 exclusion of alternatives, and no mention of the sibling list_threads despite it covering an overlapping resource. The description only implies usage through the verb "search".

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 usefully discloses two non-obvious behaviors: the bridge converts to .m4a if needed, and file_path is read on the bridge host (not the caller). It does not cover failure modes, permissions, or subscription prerequisites beyond the implicit 'sole subscribed target' hint.

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 the core behavior in the first sentence and uses the Args block efficiently to document the two parameters. Slightly boilerplate formatting but no wasted prose.

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. For a 2-param tool the description covers purpose, host-side path semantics, format conversion, and target resolution adequately; only error/permission behavior is 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%, so the description must compensate, and it does: it explains file_path is resolved on the bridge host and that `to` is a chat alias that can be omitted to target the sole subscribed chat. This adds meaning beyond the bare schema field names and default.

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 (send) and resource (audio file delivered as a voice message), which is more precise than the generic sibling send_file. The conversion note further distinguishes it from a plain file send. It does not explicitly name its siblings, 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?

No when-to-use or when-not-to-use guidance and no alternatives named. The agent must infer that this is for audio/voice versus send_file or share_media on its own, which is exactly the choice that needs guidance.

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

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

With no annotations, the description carries the full load and does meaningful work: the path is resolved on the bridge host (not the caller's machine), only photo/video are accepted, view_mode produces disappearing media, and videos must be H.264 mp4. It omits failure modes, size limits, and permission requirements, but the host-resolution disclosure is exactly the kind of context annotations would otherwise have to supply.

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 the what and the hard constraint in one sentence, then presents parameters as a compact Args block. Only mild redundancy between the host-path sentence and file_path's parenthetical.

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. For a mutation tool with zero annotation coverage and zero schema descriptions, the description supplies the file-type restriction, host path semantics, and view_mode behavior, leaving only edge cases uncovered.

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 documents all three params: file_path (resolved on the bridge host), to (chat alias with omit-to-default behavior), and view_mode (once vs replayable with format implications). Only missing details like path format or alias resolution rules keep this from a 5.

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 ('Send a photo or video') and immediately narrows the resource with an Instagram DM constraint. It plausibly separates itself from send_audio (audio-only), though the boundary with the sibling share_media is not addressed.

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 real conditional guidance for two params ('Omit for the sole subscribed target', 'Omit for a normal one'), which implies usage. However, it never says when to prefer this over send_audio or share_media, so alternative selection is left to inference.

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 behavioral burden. It helpfully discloses the user-visible effect ('they see typing...') and that the tool is optional, but omits other traits such as how long the indicator persists, whether it auto-expires, authentication requirements, or rate limits.

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

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

The description is short and front-loads the purpose before the Args list. Every sentence contributes, though the mixed inline quoting around 'typing...' is slightly awkward.

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, all-optional tool with an output schema, the description covers purpose, the visible effect, and both parameters adequately. Usage relative to alternatives is the remaining gap, but nothing critical for invoking it correctly is 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%, so the description must compensate. Its Args section documents both parameters: 'to' (chat alias, omit for sole subscribed target) and 'composing' (true starts, false stops), adding real meaning beyond the bare schema titles, though format details for the alias are absent.

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 action and its observable effect: it sends a typing indicator that recipients see as 'typing...' while composing is true. This is a distinct action with no sibling that does the same thing, but the description does not explicitly contrast itself with neighboring tools like set_idle or reply.

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?

'Optional' and 'while composing is true' imply the context of use, and the 'to' note explains the sole-subscription fallback. However, there is no clear statement of when to use this versus, say, simply replying, nor any exclusions or prerequisites.

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 behavioral burden and does disclose the key non-obvious side effect: it resets to the default the moment they next message. It also explains the two meaningful value semantics (60 = hourly, 0 = pause). It omits any permission or scope prerequisites, keeping it short of a 5.

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-loaded with the purpose, then the practical example, then the reset note and an Args block. Every sentence contributes; the only minor cost is the slightly redundant Args listing, but it earns its place given zero schema descriptions.

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. For a two-parameter configuration tool the description covers purpose, both params, value semantics, and the auto-reset behavior. It lacks only permission/prerequisite disclosure, which is minor here.

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, and it does: minutes is defined as the quiet-time threshold in minutes with 0 meaning pause, and to is described as a chat alias that can be omitted for the sole subscribed target. Both of the two parameters gain meaning beyond the bare 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?

States a specific verb-plus-resource: tuning how long a chat must be quiet before an idle nudge fires. This is clearly distinct from all siblings (subscribe, mute_thread, etc.), none of which manage idle-nudge timing. It stops just short of naming a sibling or scope boundary, so 4 rather than 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 concrete usage context: ramp it up to back off (60 = hourly) or set 0 to pause. It also flags the auto-reset behavior. There are no explicit when-not or alternative tools named, but no sibling competes for this job, so the 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 are provided, so the description carries the full behavioral burden. It reveals only that this is a share (a mutation) into a thread; it says nothing about whether the share is visible to other participants, idempotency, permissions/auth requirements, rate limits, 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?

The action is front-loaded in the first sentence, followed by a compact two-entry Args block with no filler. It is appropriately sized for a two-parameter tool.

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, but for a mutation tool with zero annotations the description leaves out key context: side effects, permission requirements, and how it relates to the many thread/message siblings. What remains is not enough for an agent to invoke it confidently in ambiguous cases.

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 partly does by defining both parameters: media_id as the Instagram media/post ID and thread_id as the target thread. Neither accepts format detail (e.g., numeric ID vs. shortcode) or an example, so the clarification is adequate but shallow.

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 specific verb and resource: 'Share an Instagram post into a thread', which is concrete enough for an agent to know the action. It does not, however, distinguish itself from the sibling 'share_profile' (or 'open_share'/'transcribe_share'), so the agent has to infer the boundary between sharing a post versus a 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?

There is no when-to-use or when-not-to-use guidance, and no alternative tool is named. The phrase 'into a thread' implies the context (an existing thread must be targeted), but nothing tells the agent how this differs from reply/send_file or from the sibling share_profile.

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 the full behavioral burden. It says the profile is posted into a thread but discloses nothing about side effects (notifications to participants), required membership/permissions on the target thread, or failure conditions.

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-to-three short lines with the action front-loaded; the args block is efficient and wastes no words. Slightly formulaic, but every sentence earns its place.

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

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

An output schema exists, so return values need not be explained, and both inputs are covered. What remains missing for a cross-user share action is context about permissions, thread membership requirements, and any side effects.

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 does: both parameters are annotated inline ('ID of the user profile to share', 'Thread to share it into'). This goes meaningfully beyond the bare schema names, though thread_id's note is close to a restatement.

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 ('Share') and resource ('a user's Instagram profile') plus the destination ('into a thread'), which is enough to distinguish it from siblings like share_media or open_share. It stops short of explicitly naming the alternative, so the profile-vs-media distinction is left implicit.

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 such as share_media or open_share. The agent must infer the trigger condition from the verb 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose two useful traits: that only subscribed chats deliver events, and that this is the sole entry point for raw thread ids. However, it omits idempotency (does re-subscribing error or overwrite?), permission requirements, and what happens to an existing alias on conflict.

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-loaded with the purpose, then the key scoping rule, then a structured Args block. Efficient and skimmable, with only minor redundancy between the alias definitions.

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. For a two-parameter mutation tool the description covers purpose, sourcing of ids, the alias fallback, and the side effect of subscribing; only edge-case behavior (re-subscribe, alias collision) is 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%, so the description must compensate, and it largely does: chat_id is explained with a concrete example value, and alias is defined semantically plus given a fallback rule ('Derived from the thread title if omitted').

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 (Subscribe) and resource (Instagram thread), plus a secondary effect (assign a short alias). It also explicitly positions itself as 'the ONE place a raw thread id is entered', which distinguishes it from list_threads/search_threads and the other 25 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?

Gives clear context for when this matters ('Only subscribed chats deliver events') and names where chat_id comes from (list_threads or search_threads). It stops short of explicitly contrasting with unsubscribe/list_subscriptions or stating exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses a non-obvious gotcha (music-only reels produce noise) and the fact that it reuses the open_share download, but says nothing about permissions, cost/latency, or failure behavior for a tool that fetches and processes remote media.

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 the purpose, follows with the scoping caveat, then details the two args. No wasted sentences; the only quibble is that the 'Args' block is fairly terse in formatting rather than prose.

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. For a 2-param transcription tool the description covers purpose, usage exclusions, and both parameters adequately; only operational context like auth or rate limits is absent.

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, and it does: message_id is explained with its source ('from the channel event') and to is explained with its default semantics ('Omit for the sole subscribed target'). Both parameters gain meaning beyond the bare schema types.

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 (transcribe) and resource (a shared reel's or post's videos), which is unambiguous. It also clarifies its relationship to open_share, but does not explicitly contrast itself with any sibling for other use cases, 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 a clear when-to-use rule ('Only when the words matter') plus an exclusion ('music-only reels give noise'), which is genuine guidance on when not to use it. It stops short of naming an alternative tool for cases where only the media (not the words) is needed.

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 behavioral burden. It identifies the state change but does not disclose permissions, reversibility, side effects, or what happens if the thread is not currently muted.

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 extremely short and front-loaded. Every sentence is useful, and there is 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 described. However, with no annotations, the description should provide more behavioral context for a state-changing operation; it remains minimally viable for invocation but thin on safety and usage 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 single parameter is briefly explained as 'ID of the thread to unmute.' With 0% schema description coverage, this is the only documentation, but it adds little beyond the parameter name and does not specify format or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Unmute notifications for a thread.' It is immediately distinguishable from the sibling mute_thread and other messaging 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?

No when-to-use guidance, prerequisites, or alternatives are given. The agent can infer that the tool reverses mute_thread, but the description itself provides no explicit routing or 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, so the safety profile is covered. The description adds real value beyond that by specifying the destruction scope ('for everyone') and noting it also covers messages the owner sent from their phone, which is non-obvious behavioral context.

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 core action is front-loaded in a tight first sentence, but the middle paragraph is conversational and rambling ('That covers yours and the ones the owner sent from their phone: when the operator tells you to delete one, do it'), and the awkward line breaks dilute structure.

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?

Output schema exists, so return values needn't be described. The description covers action, scope, id source, and target semantics for a two-parameter destructive tool; only permission requirements and irreversibility confirmation are absent.

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 the 'to' parameter meaningfully (chat alias, omit to target the sole subscribed target), but the message_id entry ('Id of the message') merely restates the schema title, leaving the more useful detail to the get_message_ids cross-reference.

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 ('Unsend a message this account sent') plus scope ('for everyone'), which distinguishes it from send/reply siblings. An agent knows exactly what operation this is without opening the schema.

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?

Routes the agent to get_message_ids for the required id and states when to act ('when the operator tells you to delete one, do it'). It gives clear triggering context but no explicit when-not guidance or comparison against alternatives like hide_thread.

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 behavioral burden. It discloses the effect (events stop delivering) but says nothing about idempotency if the caller is not subscribed, reversibility, or any auth/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?

Two tight sentences plus a compact Args block, with the core purpose front-loaded. Slightly verbose formatting but no wasted content.

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. The description covers the parameter and effect, but for a state-changing subscription tool it omits edge cases such as unsubscribing from a non-subscribed chat.

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 'to' parameter, but the Args block compensates by telling the agent it accepts 'Alias or thread id'. This adds meaningful disambiguation beyond the bare 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 gives a specific verb+resource ('Unsubscribe from a chat') and states the effect ('Stops delivering its events'). It is clearly the inverse of the sibling 'subscribe', though it never names or contrasts with that 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?

There is no explicit guidance on when to use this tool versus alternatives like subscribe, set_idle, or list_subscriptions, nor any note on pruning/prerequisite state. The usage is at best implied by its function.

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