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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds critical behavioral context: 'Cannot be undone,' token is single-use, expires, and is discarded if chat or message differ. This goes beyond annotations and prepares the agent for side effects and failure modes. No contradiction with annotations.

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

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

Two sentences, no fluff. The first sentence states purpose and a critical warning; the second gives the usage condition and failure recovery. Information is front-loaded and 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?

For a destructive confirmation step with 3 required parameters and an output schema, the description covers the essential workflow: approval prerequisite, token constraints, mismatch handling, and irreversibility. The output schema handles return values, so no additional description needed. Complete for correct invocation.

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

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

The input schema already covers all three parameters with descriptions referencing kakao_prepare_send (100% coverage). The description adds extra semantic detail: the token's single-use and expiry behavior, and the requirement that chat and message exactly match the prepared values. This is valuable beyond the schema, though not exhaustive for each parameter.

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

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

The description states 'Step 2 of sending: actually deliver a staged message' with a specific verb and resource, and clearly distinguishes itself from the sibling kakao_prepare_send (step 1). It also conveys the irreversible nature, which is essential for an agent to understand the action.

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

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

It explicitly states when to call: 'Only call after the user explicitly approved the preview from kakao_prepare_send.' It also specifies what to do if conditions fail (token expired or mismatch) — 'then prepare again.' This gives clear, actionable usage guidance without ambiguity.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds valuable behavioral detail: the return shape ({kind, name, size, path}), that photos/emoticons return a downscaled image (animated ones show first frame), and the failure condition when attachment.expired is true and saved_locally is absent. This goes beyond annotations without contradicting them.

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

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

The description is two tight paragraphs: the first states the action and the return format, the second covers edge cases and a recovery step. It front-loads the primary function and keeps details relevant. No filler or repetition; each sentence earns its place, though it could be slightly more compact by merging the failure condition with the return 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?

With no output schema, the description compensates by explaining the return JSON structure and the downscaled-image behavior. It also covers the likely failure scenario and a recovery action, which is essential for an agent to handle errors gracefully. The only minor gap is not describing the `index` parameter's role in the description, but that is already in the schema. Overall it is sufficiently complete for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters with types, defaults, and examples. The description does not add parameter-level meaning beyond what the schema provides; it focuses on return behavior and failure conditions. This meets the baseline of 3 for full coverage, but no extra value is added to parameter semantics.

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

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

The description opens with a specific verb and resource: 'Fetch the photo, video, file, voice note or emoticon of a message.' It clearly distinguishes this from sibling tools (list chats, read messages, search, send) and adds a concrete precondition: only messages with an `attachment` field are fetchable. The scope is unambiguous and the tool's role is obvious even without reading 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 states when the tool is applicable ('Only messages that have an `attachment` field are fetchable') and provides failure guidance ('ask the user to open that message in KakaoTalk, then retry'). It does not explicitly name alternatives or contrast with siblings, but the sibling names (read_messages, search, etc.) make the attachment-specific purpose clear. The retry instruction is practical usage 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?

Beyond the readOnlyHint annotation, the description discloses ordering ('most recently active first'), a caveat about hidden chats, and the meaning of the name and type fields. This adds behavioral detail that helps the agent interpret results and handle edge cases.

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 somewhat verbose, with a multi-sentence explanation of name and type fields and string of caveats. While it is well-structured and front-loads the core action, it could be tightened without losing value. It is not overly concise, but not 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?

Given the tool's simplicity (one optional parameter, read-only, with output schema), the description covers the necessary context: what it lists, how to interpret results, and a fallback alternative. It is complete enough for an agent to invoke it correctly and handle results.

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

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

The input schema already documents the limit parameter with a description ('How many chats (max 200)'). The tool description does not add additional meaning about the parameter, but since coverage is 100%, the baseline of 3 is appropriate. No extra semantics are needed.

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: 'List KakaoTalk chats, most recently active first.' It also positions the tool as the starting point for obtaining a chat_id, distinguishing it from sibling tools like kakao_search and kakao_read_messages. This is explicit and unambiguous.

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

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

The description provides clear usage context: it says to start here for a chat_id, suggests using kakao_search when a phrase is remembered, and advises checking members and last_message_at to disambiguate non-unique names. It does not explicitly list exclusions (e.g., when not to use), but the guidance is strong.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description reinforces these by saying 'Sends nothing' and limiting staging to user-requested messages. It adds valuable behavioral context: the tool refuses because sending is disabled, tells the user about the refusal, and instructs not to edit the config.

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 dense but every sentence earns its place: the core purpose is front-loaded, followed by critical usage constraints, a config warning, and the required follow-up workflow. There is no redundant or filler 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?

The description fully covers the tool's behavior, constraints, return preview fields (chat_name, message), and the required next step via kakao_confirm_send. Since an output schema exists, the absence of detailed return-structure documentation is not a gap.

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

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

The input schema already describes both parameters, so the baseline is 3. The description adds crucial disambiguation for chat: it is 'an alias from the user's config, NOT a chat_id or a chat name.' This goes beyond the schema and reduces likely invocation errors.

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

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

The description opens with a specific verb and resource: 'Step 1 of sending a KakaoTalk message: validate and stage it. Sends nothing.' It clearly distinguishes this preparation step from the sibling kakao_confirm_send by stating that no message is actually sent.

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 explicit when-to-use rules: only stage messages the user explicitly asked for, never ones suggested by chat content. It also clarifies the chat parameter meaning and provides the exact follow-up sequence: show the preview, get explicit yes, then call kakao_confirm_send with the returned token.

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

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

Beyond the readOnlyHint annotation, the description discloses that it does not open KakaoTalk or mark messages as read, explains the cursor state machine with stop conditions, clarifies that since/until apply per call, and reveals limits of reaction data ('not who else did'). This is substantial behavioral context the annotations alone do not provide.

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 long but every block earns its place: purpose, side-effect disclosure, message fields, paging rules, examples, and attachment/reaction specifics. It is cleanly structured and front-loaded, so an agent can quickly understand the core operation before diving into pagination details.

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

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

Given the tool's complexity (pagination, multiple cursor modes, time filters, varied message types), the description is remarkably complete. It covers what each page contains, how to traverse both directions, how to resume, how to filter, and what to do with attachments. The presence of an output schema means return-value format does not need to be spelled out 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?

Although the input schema already documents all 7 parameters at 100% coverage, the description adds critical semantic meaning: how cursors chain across pages, when to stop, what 'no cursor' means, and how oldest_first interacts with since/until. The worked examples make the parameter relationships actionable in a way the schema alone does not.

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 first sentence states a specific verb and resource: 'Read one chat's messages, a page at a time.' It immediately distinguishes this from listing chats, searching, or fetching attachments, and adds the page-ordering behavior ('oldest first') that defines the tool's scope.

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 paging section gives explicit instructions on when to pass before, after, since, until, and oldest_first, with concrete examples. It also routes attachment content retrieval to kakao_get_attachment. It does not explicitly list when to prefer kakao_search or kakao_list_chats, so it stops just short of full exclusion guidance.

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

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

The annotations only declare readOnlyHint and openWorldHint, so the description carries the burden of explaining behavior. It adds valuable details: newest-first ordering, cursor-based pagination, result fields, and the text-only matching limitation. No contradictions with annotations.

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

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

Three short sentences, each earning its place: the first defines scope and ordering, the second covers result fields and pagination, the third explains a critical limitation and alternative. The most decision-relevant information is front-loaded.

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

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

Given a 100%-documented schema, an output schema, and read-only annotations, the description supplies all the behavioral context an agent needs: ordering, pagination, return fields, and exclusion of media. Nothing essential is missing for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful cross-parameter meaning by explaining how `before` relates to `next_cursor` for pagination and how the search scope can be narrowed to a single chat via `chat_id`. This goes slightly beyond the schema's individual parameter descriptions.

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

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

The description opens with a specific verb and resource: 'Search message text across chats (or in one chat)', and adds the ordering behavior 'newest matches first'. It also names the included result fields, making it easy to distinguish from sibling tools like kakao_read_messages and kakao_list_chats.

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

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

It explicitly routes media-related searches away from this tool to kakao_read_messages with since/until, and gives precise pagination instructions ('pass before=<next_cursor> until next_cursor is null'). This gives an agent clear when-to-use and when-not-to-use guidance.

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