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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly covers the safety profile: the tool prefills the message, stops, and leaves sending to the user. It also states behavior for empty body and service transport selection, which goes beyond basic schema details.

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 front-loaded with the most important fact (does not send), then gives the safety rationale, routing guidance, and compact parameter docs. Every sentence adds value and none are redundant with the 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 tool is a simple three-parameter compose action with an output schema, and the description covers all parameters, the core behavior, the user-visible side effect, and the distinction from send_message. Nothing an agent needs to invoke 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 is the only source of parameter meaning. It compensates fully: handle gets a concrete example, body explains prefill behavior and emptiness, and service gets explicit valid values and meaning ('which transport Messages preselects').

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

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

The description clearly states a specific verb and resource: 'Open Messages with a recipient and text prefilled, WITHOUT sending.' It immediately distinguishes itself from send_message and names exactly what the tool does not do, so an agent can tell it apart from the sibling tool 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?

The description gives explicit routing guidance: 'Prefer it over send_message, and use it whenever the conversation does not exist yet — send_message can only reply to an existing one.' This tells the agent when to choose this tool and when to choose the alternative.

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

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

With no annotations provided, the description carries the full burden. It discloses the retrieval behavior and the base64 encoding, but it does not mention potential side effects, error conditions, size limitations, or response structure. For a read-only retrieval tool this is adequate but not rich.

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 minimal and focused: one clear sentence defining the operation, followed by a short, relevant parameter note. Every word contributes to understanding the tool's purpose and usage.

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

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

For a tool with a single parameter and an output schema, the description covers the key operational detail (base64 encoding) and parameter origin. It does not explain what the returned object looks like, but the presence of an output schema reduces the need for that in the description.

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 adds valuable meaning by explaining where attachment_id originates (`from get_message`). This goes beyond the schema's bare integer type and helps the agent source the correct identifier.

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: 'Retrieve an attachment's bytes' with the encoding detail (base64). This clearly distinguishes it from sibling tools like get_message, which retrieves message metadata rather than binary content.

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

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

It specifies that the attachment_id comes from `get_message`, which gives clear contextual guidance on how this tool fits into a workflow. It does not explicitly discuss alternatives or when-not-to-use, but the associated source of the ID is a strong usage 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?

No annotations are supplied, so the description carries the burden and does disclose meaningful behavior: oldest-first ordering, paging semantics via before_id, and Claude-side rendering as an inline card. It stops short of stating read-only safety, rate limits, or default truncation consequences.

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 core action, then the rendering caveat, then args. Every sentence is useful, though the Claude-specific rendering note is slightly verbose for an agent-facing definition.

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

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

With an output schema present, the description needn't explain return values, and params are all covered. For a scoped, read-only read tool this is close to complete; the only gaps are the missing explicit read-only/rate-limit framing.

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: chat_id is tied to list_chats, limit is defined as max messages with default 50, and before_id is explained as "older than this message id, to page back through history." It could go further on boundary behavior, but all three params are meaningfully covered.

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 ("Read messages") scoped to "one conversation," and adds the ordering guarantee (oldest-first). It implicitly separates itself from conversation-wide search, though it does not name search_messages or get_message 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 implied rather than stated: it tells the agent to page back with before_id and points at list_chats for the chat_id source, plus a rendering hint. There is no explicit when-to-use-this-vs-search_messages/get_message guidance or when-not condition.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses the return content (attachments, delivery times) and that it renders as an inline card, which is useful for response formatting. However, it does not state whether it requires authentication, whether it is read-only (implied by 'Read'), or any rate limits 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?

Front-loaded with the core action and result content, then a separate practical instruction about rendering, then the argument. It is appropriately sized for a simple getter. The 'Args:' section is slightly redundant given the schema, but not wasteful.

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

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

Given the tool's simplicity (one required param, output schema exists), the description provides enough to invoke correctly and sets expectations about the return format. Missing explicit usage boundaries against sibling list/search tools, but overall complete for this scope.

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%, meaning the message_id parameter has no schema-level description; the description alone documents it as 'Message id from search_messages or get_chat_messages'. For a single required parameter with zero coverage, this is the minimum viable but still does not explain format or constraints beyond the example source.

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 (Read) and resource (one message) with explicit scope ('in full, including attachments and delivery times'). It is clear this retrieves a single message, distinguishing it from list_chats, get_chat_messages, and search_messages.

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?

Implicitly guides the agent by naming the source of message_id ('from search_messages or get_chat_messages'), establishing the prerequisite discovery step. It does not explicitly state when-not to use it (e.g., versus get_chat_messages for bulk retrieval), leaving a small gap.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the content returned, which implies a read-only aggregate query, but it does not explicitly state that it does not modify data or that it reflects the current database state. The disclosure is adequate but not thorough.

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

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

The description is a single, well-structured sentence that front-loads the resource ('Messages database') and then lists the key statistics returned. There is no fluff or redundancy; every phrase adds informational value.

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

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

For a zero-parameter, read-only statistics tool with an output schema, the description provides sufficient context on what to expect: totals, counts, breakdown, and date range. No critical missing information is apparent; an agent can correctly decide when and how to invoke this tool based on the description alone.

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

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

The tool has zero parameters, so the schema is trivially complete. The description goes beyond the schema by explaining the kind of information returned, which is useful for an agent deciding whether to call it. Baseline for zero-parameter tools is 4, and the description earns it.

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

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

The description clearly states the tool provides an overview of the Messages database with specific aggregate statistics (message/chat totals, unread count, attachment count, per-service breakdown, date range). This distinguishes it from sibling tools like list_chats or get_chat_messages, which fetch individual records rather than summary data.

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 use when a high-level overview of the entire database is needed, but it does not explicitly state when to choose this over alternatives, nor does it mention exclusions or alternatives. The usage context is clear but 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 burden. It discloses the ordering guarantee and the host-side rendering behavior (inline card, don't repeat contents), which is genuinely useful context, but it never states read-only semantics, page-size limits, or what happens when limit exceeds the total conversation count.

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 ordering are front-loaded in the first sentence, followed by the host-rendering note and compact parameter list. The Claude-specific rendering paragraph is somewhat verbose but earns its place by preventing duplicated output.

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 zero-annotation list tool the description covers purpose, ordering, paging, and host display adequately; the only real gap is not routing the agent away from sibling retrieval/search tools.

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 document the parameters and it does: limit as maximum conversations to return with default 30, and offset as conversations to skip for paging. It adds meaning for offset beyond the bare schema, though it adds little beyond the schema's own default for limit.

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 conversations') plus the sort order ('most recently active first'), which the agent cannot infer elsewhere. It does not, however, name or distinguish itself from the closest siblings (get_chat_messages, search_messages), 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?

Usage is implied by 'List conversations' — browsing rather than reading or searching a specific conversation. There is no explicit statement of when to prefer this over search_messages or get_chat_messages, and no prerequisites or exclusions are given.

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

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

With no annotations, the description carries the behavioral disclosure burden. It openly states that the first build decodes every message and takes a while, and that rebuild discards the index and decodes everything again, which communicates the costly and somewhat destructive nature of a rebuild. It could go further on side effects or performance expectations, but the key behavioral traits are disclosed.

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

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

The description is compact and well-structured: a one-line summary, a clearly labeled usage rationale, and an Args section that explains the only parameter. Every sentence contributes useful information, and the key facts are front-loaded.

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

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

Given the tool has only one parameter, an output schema, and no annotations, the description provides all essential context: what the tool does, when it is needed, and what the rebuild flag means. The wording about the optional nature and the purpose of rebuilding makes this fully actionable for an agent.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining the single parameter 'rebuild' in meaningful terms: it discards the index, decodes every message again, and is needed only to pick up edits older than the recent-edit window. This adds substantial decision-making value beyond the bare boolean schema definition.

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

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

The description clearly states a specific action ('Update the local search index') and a reporting behavior, so an agent knows exactly what the tool does. It also distinguishes itself from search_messages, which maintains the index automatically, preventing confusion among sibling tools.

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

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

The description explicitly says calling this tool is optional because search_messages keeps the index current, then gives concrete use cases: warming the index deliberately and forcing a full rebuild. This gives an agent clear conditions for when to invoke this tool versus relying on search_messages.

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 so well: it discloses that results come from a local decoded-body index kept up to date automatically, that the first search on a large history is slow while later ones are fast, and that results render as an inline card that shouldn't be repeated. It does not state the ordering of global (non-chat-scoped) results or any permission/auth constraints.

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, then index/latency behavior, then rendering guidance, then the arg list — a sensible order with no filler. The rendering note is arguably tangential to tool selection but is genuinely useful invocation context, so the extra length is defensible.

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 six-parameter search tool with no annotations and 0% schema coverage, the description covers purpose, latency behavior, output rendering, and every parameter. The output schema handles return values, so the only mild gap is the unspecified ordering of results when no chat_id is given.

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 supply all parameter meaning, and it documents every one of the six: query as case-insensitive substring, limit as max results with default 30, chat_id scoped to list_chats, from_me sent/received polarity, and after/before as inclusive 'at or after'/'at or before' bounds. The inclusive boundary semantics are extra information the schema's date-time types do not convey.

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 explicit scope: 'Search message bodies across every conversation, over all history.' It distinguishes itself from the narrower retrieval siblings by emphasizing 'every conversation' and full history, though it never names an alternative like get_chat_messages. Adding the case-insensitive substring detail further pins down what 'search' means here.

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 conditions: leave query out to search filters alone, and 'chat_id plus a date range with no search term reads one conversation newest-first.' It also points to list_chats as the source of chat_id. It stops short of explicitly saying when to prefer this over get_chat_messages or refresh_search_index.

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 — and it delivers. It discloses immediacy ('delivers immediately'), irreversibility ('scripting cannot unsend it'), automatic transport selection (iMessage/SMS/RCS), and why the tool addresses a chat rather than a raw handle. This is precisely the behavioral context an agent needs before invoking an irreversible action.

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?

Well-structured with the critical IRREVERSIBLE warning front-loaded immediately after the one-line purpose. The compose_message alternative is mentioned twice, but each mention serves a distinct routing case. Slightly longer than strictly necessary, yet every sentence carries safety-relevant content, so the length is earned.

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 safety-critical, irreversible tool with zero annotations and zero schema descriptions, this is remarkably complete: it covers safety guardrails, when-to-use routing, transport behavior, parameter sourcing, and the confirm requirement. An output schema exists, so return values need not be documented. Nothing essential for correct invocation 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 — it does fully. chat_id is sourced from list_chats, body is defined as text, and confirm is documented as 'Must be True' with its safety purpose explained. Notably, the schema marks confirm as optional with default false, and the description corrects this dangerous ambiguity by stating the requirement explicitly.

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 ('Send a message to an existing conversation') with an unambiguous verb+resource pair. It distinguishes itself from sibling compose_message by explicitly scoping to existing conversations, and from the read-only siblings by naming the mutation it performs.

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

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

Explicitly names compose_message as the alternative in two distinct routing conditions: when the user has not clearly asked for sending, and when starting a new conversation. Also instructs the agent to confirm recipient and wording with the user before calling, leaving no ambiguity about when this tool is appropriate.

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