MindThread

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

Annotations already flag this as non-read-only, destructive and open-world, and the description explains why: queued items publish automatically at schedule_times, i.e. the write leaves the system. It also adds two facts annotations cannot convey — the 20-item cap and that each text is validated against the account's content_rules. It stops short of stating failure behavior (what happens when content_rules rejects an item) or that calls are non-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?

The first two sentences are dense and front-loaded with the useful facts: batch cap, item shape, status behavior, content_rules validation. The final sentence is a dangling, ungrammatical fragment that repeats the status question already answered and dilutes the message rather than earning 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 3-parameter mutation tool with no output schema, the definition covers the important ground: what can be added, the batch limit, validation against content_rules, and the publish timing tied to schedules. Gaps are the return shape after a partial failure and the non-idempotency already declared in annotations but never explained in prose.

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, but the description goes beyond the schema by defining the operational consequence of the status enum (queued = publishes at schedule_times; draft = waits for approval) and by clarifying that media_urls must be public https images. That converts a bare enum label into actionable 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?

States a specific verb and resource ('Adds up to 20 items ... to an account's library') and enumerates the item shape (text, optional public https images) plus the two statuses. Sibling tools like update_library_item or bulk_queue_library are not named, so the boundary is left implicit, but the batch-add semantics are unmistakable.

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 status sentence implies when to choose queued (auto-publishes at schedule_times) versus draft (waits for approval), which is genuine selection guidance. However, the closing clause ('Applies after drafts are approved by the user and should enter the daily publishing queue, or should be parked as drafts') is garbled and reads as a truncated fragment, and no sibling alternative is ever named.

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 cover read-only, idempotent, non-destructive and closed-world. The description adds genuinely useful semantic behavior beyond that: views_scope is lifetime while posts_scope is the period, a non-obvious distinction. It says nothing about aggregation semantics for "all" or behavior for missing accounts, keeping it at 4.

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

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

Three compact sentences, front-loaded with the returned metrics and the required argument. No filler, though the scope sentence refers to fields that do not appear in the schema, which is minor friction.

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 only two simple parameters, no output schema and annotations handling the safety profile, the description covers what an agent needs: metrics returned, time window, aggregation option. Missing only return shape and edge-case behavior.

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 both parameters are already documented, including the "all" value and the 30d default. The description repeats those facts and introduces views_scope/posts_scope, which are not actual parameters, so it adds little and risks confusing the agent. Baseline 3 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?

Names a specific verb and resource: returns views, likes, replies and followers for one account over a period. A reader knows exactly what data comes back. It does not differentiate from any sibling (e.g. get_my_usage, list_events), so it falls 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?

"Applies when the user asks how an account is performing" gives a clear trigger condition. It states no exclusions and names no alternative tool for org-level or per-post analysis, so usage is contextual rather than fully routed.

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 destructive=true, idempotent=true, openWorld=false, but the description adds substantial context: per-account transactions, three-way per-row outcome (ok/unchanged/failed with reason), a 24-hour revert window via batch_id, and the fact that sensitive-field confirmation may block on owner approval. It doesn't describe rate limits or what happens to rows beyond 100, 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?

One dense paragraph that front-loads the write semantics, result shape and revert path before the constraints. Every sentence carries information, though the trailing 繁中 restatement duplicates content already given in English.

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 carries the return contract itself (per-row ok/unchanged/failed plus reason, and batch_id), and it covers the transactional guarantee, the idempotency contract and the preview gate. An agent has everything needed to invoke this destructive bulk write correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by stressing that idempotency_key is required and that a retried request with the same key returns the first result, and that a preview_id not matching the changes is refused. confirm_sensitive gains the consequence that confirmation may wait for owner approval, which the schema does not say.

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+scope: writes a batch of settings changes to up to 100 accounts, each in its own transaction, returning per-row results and a batch_id. It is clearly distinguished from preview_account_settings (must be called first), update_account_settings (single-account sibling) and revert_account_settings_batch (the undo path).

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 ordering rule: nothing is written without a preview, preview_id from preview_account_settings is required from Claude/ChatGPT connections, and the tool applies only after the user has seen and confirmed the preview. It also names the undo alternative (revert_account_settings_batch within 24h) and the case that requires confirm_sensitive:true.

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?

Goes well beyond the annotations by disclosing concrete failure semantics: held_reason publish_result_unknown returns 409 publish_result_unknown because the item may already be live on Threads, and in-flight publication returns 409 publishing_in_progress. What it omits is post-success behavior (does approval schedule, publish immediately, or just queue?) and any reversibility note, which matters for a destructiveHint=true 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?

Three sentences, zero filler, with the core action front-loaded before the exception cases. Every clause carries actionable 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?

For a single-parameter mutation with no output schema, the description covers action, scope, invocation condition, and the two realistic conflict responses. The only gap is downstream effect on the item, which is minor given how precisely the error states are enumerated.

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% with a single documented 'id' parameter, so the baseline applies. The description repeats 'by id' without clarifying whether this is a library item id, a draft id, or an approval id, which is the one detail the terse schema leaves ambiguous.

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 concrete verb and resource ('moves one draft into the publishing queue by id') and the word 'one' implicitly contrasts with the bulk sibling, bulk_queue_library. It never names that sibling outright, so the differentiation is inferred rather than explicit.

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?

'Applies when the user approves a single draft' gives a clear triggering condition, and the two 409 cases effectively describe states where the call should not be attempted. It stops short of pointing to alternatives (bulk_queue_library for multiple items) or stating what to do after a 409.

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 flag destructive/non-idempotent/open-world, but the description adds real context beyond them: the reply is posted to Threads immediately (external, non-reversible publication), the optional text must pass the same quality gates as generated content, and the call 'may wait for the owner's confirmation' (a latency/blocking hint). It doesn't say what happens on failure or whether a sent reply can be undone.

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 verb, resource, and effect, then adds constraints. Three clauses are dense but each contributes; the 'may wait for owner's confirmation' note is buried mid-sentence rather than flagged prominently.

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, non-idempotent write with no output schema, the description covers the external side effect, the validation of edited text, and possible confirmation waiting. Only failure/rollback behavior is unaddressed, which is a minor gap given the annotations.

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 baseline is 3; the description earns extra by clarifying that 'reply' is an optional edited text validated against the same quality gates, and that 'id' targets a single pending draft.

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 ('Approves one drafted cloud patrol reply by id') plus the concrete effect ('sends it to Threads now'). The pairing of approve/send plus the singular 'by id' scope distinguishes it cleanly from list_pending_replies and reject_pending_reply without naming them.

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 gives the triggering condition: 'Applies when the user has read a pending draft and wants it posted.' That is a clear use context, though it never names reject_pending_reply as the alternative when the draft should not be sent.

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 annotations (destructive, non-idempotent, open world), it discloses that the previous digest is replaced, that the call consumes one AI generation, and that dry:true returns a preview without saving. That is exactly the cost/destruction/preview context an agent needs but cannot infer from structured fields.

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

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

Four dense sentences, front-loaded with what the tool does and the destructive replace semantics. Nothing is padding, though the lifecycle sentence could be tightened and the generation-cost note sits mid-block rather than up front.

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?

A destructive, quota-consuming mutation with no output schema and full annotation coverage is well served here: replacement, cost, preview, and cadence are all stated. It does not say what the digest is used for or that get_material reads it back, which is a minor residual 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?

Schema coverage is 100%, and the description largely restates it (8 https pages, 6,000 characters, dry preview). It adds one genuinely new constraint – that the URLs must be the brand's own website – but otherwise adds little beyond the schema, so baseline 3 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 (builds or rebuilds) and resource (the account's material digest), and enumerates the exact inputs it consumes: up to 8 https pages of the brand's own site, optional notes, and the account's top posts. It is clearly distinguishable from get_material, its read counterpart.

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?

"Applies once per account before the first generation, and again when the website changes" gives a concrete when-to-invoke rule and an implicit when-not. It never names an alternative sibling (e.g. get_material for reads, generate_posts for the downstream step), so the routing is clear but not fully enumerated.

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 non-readonly, non-destructive, idempotent behavior, so the description adds useful context beyond them: items leave the queue but are retained/restorable, and per-item errors can include publishing_in_progress. It does not fully describe partial-success semantics or the response shape.

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

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

Four short sentences, each doing distinct work: purpose, retention/restore behavior, error example, and usage framing. The purpose is front-loaded with no wasted text.

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 rich annotations, single parameter, and lack of an output schema, the description covers enough to invoke the tool correctly. The remaining gap is that bulk-operation return semantics, such as partial success handling, are only hinted at via the per-item error note.

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 single 'ids' parameter is already documented. The description repeats 'by id' and the max 50 limit but adds no syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('Archives ... library items') plus a clear bulk scope ('up to 50 ... in one call'). It also distinguishes the operation from deletion by explaining that archived items are kept and can be restored.

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 clear usage context: 'Applies for clearing a queue without deleting anything,' and names update_library_item as the restore path. It stops short of explicitly naming bulk_delete_library as the alternative, so it is strong but not exhaustive.

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 flag destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds genuinely useful context beyond that: the 50-item ceiling and, importantly, that failures are reported per item (e.g., publishing_in_progress), implying partial-success semantics rather than all-or-nothing. It stops short of saying whether successfully deleted items roll back on partial failure.

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

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

Three short sentences with the destructive operation and scope front-loaded, followed by failure behavior and the usage condition. No filler and every sentence carries distinct information.

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

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

With no output schema, the description helpfully sketches the failure surface (per-item errors) and the item cap. It lacks permission/authorization requirements and any note on whether items must be unpublished first, which would matter for a destructive bulk tool.

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

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

There is only one parameter and schema description coverage is 100%, with the schema itself documenting the max-50 limit. The description's 'by id' and 'up to 50' restate schema facts rather than adding format or ordering semantics, so the baseline 3 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 ('permanently deletes ... library items by id'), with a clear batch scope ('up to 50 ... in one call') and eligibility constraint ('queued, draft or archived'). The bulk-vs-single distinction from delete_library_item is implied by the 50-item cap rather than stated 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?

'Applies when the user explicitly wants items removed for good' gives a positive invocation condition and implicitly warns against casual/soft deletion. However, it never names alternatives such as bulk_archive_library for reversible removal or delete_library_item for single items, and doesn't state when this tool should not be used (e.g., published items).

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?

Goes well beyond what annotations (destructive/idempotent/openWorld) convey: it discloses the automatic publish-at-schedule_times behavior, per-item error semantics, and specifically that publishing_in_progress and publish_result_unknown can occur, warning that an item may already have been posted. That partial-failure detail is exactly the kind of context annotations cannot express.

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

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

Three tight clauses, no filler, with the core action and scale limit front-loaded and the error-handling nuance trailing. 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 one-parameter bulk mutation with no output schema, the description covers scope, scheduling behavior, and failure modes, so an agent has everything needed to call it correctly and interpret per-item errors.

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% and there is only one parameter, so the schema already carries the semantics. The description reinforces the id-based targeting and the max-50 limit consistently, adding light value but nothing the schema lacks.

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 ('Moves drafts into the publishing queue by id in one call') plus the scale cap of 50, which cleanly separates it from the singular approve_library_item and from add_library/bulk_archive_library 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?

Explicitly names the triggering condition: 'Applies when the user approves several drafts at once.' That is clear context, but it does not name an alternative or state a when-not (e.g. use approve_library_item for a single draft), so it falls short of 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?

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds useful behavioral detail about the 409 publishing_in_progress response, though it does not explain the post-cancellation state or permission requirements.

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

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

Three short sentences, front-loaded with the action and followed by the key exception and usage condition. No wasted language.

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 mutation with annotations covering safety and idempotency, the description is nearly complete. It could add what happens to the post after cancellation, but the essential behavior is covered.

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%, and the sole parameter is documented as "Post id." The description only adds "by id" without format or validation details, so the schema does the main work.

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: "Cancels a scheduled post by id." It is clearly distinguishable from sibling tools like list_schedules and schedule_text.

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 a clear usage condition: "Applies when the user no longer wants a scheduled post to go out." It does not name alternatives or exclusions, so it is strong but not exhaustive.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that with the 1-7 day retention window and the shape of what comes back (target post plus reply text) - important since there is no output schema. It stops short of describing ordering, volume or the behavior when days is omitted.

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, zero filler: scope first, then the applicability condition. Both sentences carry information the schema and annotations do not.

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-only tool with no output schema, the definition covers the window, the returned fields and the trigger condition well. Small gaps remain around default days, ordering and result volume, but nothing blocks a correct call.

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 both parameters are already documented, and the description's "last 1 to 7 days" only restates the schema's "1-7" range for days. Nothing is added about the default value when days is omitted or about account_id's format.

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 (lists replies sent by cloud patrol) plus explicit scope (last 1-7 days, with target post and reply text). The 'sent' framing implicitly separates it from list_pending_replies, but it never names that sibling, so the 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?

"Applies when the user wants to read what was actually said" gives a clear invocation condition and usefully contrasts past/sent content against a prospective action. No exclusions or explicit alternatives are given, so an agent must still decide on its own between this and list_pending_replies or cloud_patrol_stats.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered. The description adds only the 1-14 day window (which the schema also states) and the fact that top replies are included; it says nothing about result volume, per-reply grouping, or whether the window is calendar or rolling days.

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 filler, with the return content front-loaded and the routing condition second. Every clause carries information an agent needs.

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 only two parameters, no output schema, and rich annotations, the description is nearly sufficient: it says what comes back (views, likes, top replies) and when to call it. The remaining gap is the shape of the output, e.g. how many top replies are returned and whether totals are aggregated — modest for a read-only stats tool.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description's "1 to 14 days" and "for an account" merely echo the schema's bounds rather than adding format, default, or semantic 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 and resource: views and likes earned by cloud patrol replies, plus scope (1-14 days, top replies). It is clearly an analytics read rather than a configuration or log operation, but it never names the nearby cloud_patrol_log / get_cloud_patrol siblings to sharpen 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?

"Applies when the user asks whether patrol is working or which keywords perform" gives a concrete trigger condition tied to user intent. There is no statement of when not to use it and no named alternative for the log-vs-stats choice, so it stops short of 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?

Adds real behavior beyond annotations: the return is a link the user must open in a browser, the connection only materializes after the user completes the flow, and the call "may wait for the owner's confirmation." This explains why a get-style tool is annotated as not read-only, which the annotations alone would leave confusing.

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

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

Four short sentences with the return value front-loaded. The final sentence lightly restates the title's intent but doubles as usage routing, so waste is minimal.

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

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

Covers what is returned, what the agent/user must do with it, and the asynchronous confirmation caveat. Without an output schema, it could say a bit more about the link itself (expiry, single use) or what the agent should do if the wait times out.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate and no misleading parameter talk.

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

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

Specific verb and resource: "Returns a Threads OAuth link for the user to open in a browser to connect a new Threads account." It explicitly positions itself relative to list_accounts (where the result appears), so an agent can distinguish it from sibling listing/reading 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?

States the triggering condition clearly ("Applies when the user wants to add an account") and references the follow-up flow ending in list_accounts. It doesn't name an alternative tool for the case where the user already has an account connected, but the positive condition is unambiguous.

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 warn that the operation is destructive and not read-only. The description adds the important behavioral detail that deletion is permanent and that only queued, draft, or archived items are eligible, though it does not discuss permissions or cascading 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?

Two sentences, both front-loaded and purposeful. The first states what happens and to which items; the second states the selection condition and contrasts with archiving.

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

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

For a simple destructive one-parameter tool, the definition covers action, targeting, eligibility, permanence, and when to use it. Safety annotations and the input schema carry the rest, so nothing essential 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 coverage is 100%, and the single parameter is already documented as "Item id." The description only repeats the id-based targeting, so it does not add meaningful semantics beyond the schema.

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

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

States a specific verb and resource ("Permanently deletes one ... library item"), plus scope ("one ... by id") that separates it from bulk deletion and from archiving. The status list (queued, draft, archived) further narrows what this tool targets.

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 an explicit usage condition: the user must explicitly want the item gone rather than archived. That clearly distinguishes this from the archive-oriented siblings and, together with "one ... by id," from bulk_delete_library.

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?

Goes well beyond annotations by disclosing irreversibility, exactly what stops (API requests, OAuth-created webhooks) versus what keeps running (queued posts, cloud patrol settings, API-key webhooks), that pending confirmations are cancelled, the post-state 401 key_disabled, and the important side effect that a consent-page connection is shared across all sessions of a platform like claude.ai. This is exactly the context annotations cannot carry.

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 critical fact — permanent, irreversible self-disable — is front-loaded, and every clause carries distinct operational information. It is a dense paragraph with nested parentheticals that could be split for readability, but little is genuinely redundant.

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 steps in to describe the return value (the list of cancelled confirmation requests) and the post-call behavior (401 key_disabled). Combined with the destructive-annotation coverage, an agent has everything needed to call and explain this safely.

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 nothing for the description to disambiguate. Baseline 4 applies; the description correctly makes no attempt to invent parameter meaning.

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 ('Permanently disables') and a precisely scoped resource ('the key or connection making this call'), and immediately clarifies it acts only on the calling credential rather than any arbitrary key. There is no sibling that overlaps this self-revocation semantics, so the agent can distinguish it cleanly.

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 final sentence gives explicit triggering conditions: leaked credential or the user asking to stop this connection permanently. It does not name an alternative tool (none exists among siblings), so the guidance is clear but stops short of when-not-to-use framing.

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

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

Annotations cover the safety profile (readOnly false, destructive false, closed-world, non-idempotent), and the description adds real context beyond them: no publish/queue side effect, the 8,000-character context ceiling, quality tiers, and that the result surfaces rule_violations against account content_rules. It stops short of saying where drafts are persisted or whether premium quality has latency/cost implications for a non-idempotent call.

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

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

Three dense sentences, front-loaded with what is generated and how much, then constraints, then the use-case trigger. Every clause carries information; no restatement of the title.

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?

Six parameters with no output schema, and the description does cover the return-side hint (rule_violations). The remaining gap is where drafts land and whether they must be added to the library or queued separately — a material detail given the surrounding add_library and bulk_queue_library siblings.

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 earns above it by binding formula to a discovery tool ('auto, or an id from list_formulas') and restating quality tiers and the context limit in prose. It adds no enum constraint the schema lacks, but the cross-tool linkage for formula is genuinely useful.

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

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

Specific verb (generates) plus resource (post drafts) with an explicit 1-5 count range and the exact inputs that shape the output. It also carves out the negative space — 'Nothing is published or queued' — which separates it from publish, schedule_text and bulk_queue_library in the sibling list.

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 triggering condition: 'Applies when the user wants drafts to read, edit or choose from,' and routes the formula id lookup to list_formulas. It does not name the write-path alternatives (publish, schedule_text) explicitly, so the exclusion is inferred rather than stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds valuable behavioral context beyond the annotations: it explains that etag is used as if_match on update and warns that content_rules is replaced as a whole, implying the need to fetch current settings before updating to avoid overwriting.

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

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

Two sentences, front-loaded with the return fields and followed by a critical usage note. Every phrase earns its place—no redundant or vague wording.

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 read tool with one parameter and no output schema, the description is complete: it enumerates the returned fields, explains the guardrails block, and provides the key pre-update usage rationale. Nothing essential is missing for an agent to call it correctly.

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

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

Schema coverage is 100% and the only parameter (account_id) is fully documented in the schema. The description adds no additional meaning, format, or source for account_id, so the baseline of 3 is appropriate.

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

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

States a specific verb ('Returns') and resource ('one account's persona, schedule_times, ...'), listing the exact fields and guardrails block. It clearly implies a single-account read, but does not explicitly name sibling alternatives like get_account_settings_batch or list_account_settings to distinguish when to use this vs those.

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?

Provides clear context: 'Applies before any settings change, because content_rules is replaced as a whole on update.' This tells the agent when to call it, but it doesn't list exclusions or alternative tools for related operations.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds useful behavior by disclosing that rows carry failure reasons and that revertability is reported — a direct hook into revert_account_settings_batch. It does not say what happens for an unknown or expired batch_id, nor whether large batches are truncated.

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 return contract and the trigger condition in two tight clauses, no wasted preamble. The appended Chinese sentence (繁中) duplicates the purpose rather than adding information, which is a small amount of redundancy in an otherwise efficient 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?

No output schema exists, but the description compensates by naming the return shape (timing, source, counts, revert status, per-row failure reasons) and by anchoring the call to apply_account_settings. Missing only edge-case behavior (invalid/expired batch_id, pagination of very large batches) for full completeness.

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?

One required parameter with 100% schema coverage, so the schema already defines batch_id and even its provenance ('batch_id from apply_account_settings'). The description only restates that it selects exactly one batch — marginal value over the schema, so baseline 3 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 ('Returns one batch by batch_id') and then enumerates the returned facets: send time, origin channel (website/API/MCP), counts, revertability, and per-row result plus failure reason. That level of detail distinguishes it from get_account_settings, list_account_settings, and revert_account_settings_batch without opening any 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?

Gives explicit trigger conditions: 'Applies after apply_account_settings, or when the user asks what a bulk change did,' and points to apply_account_settings as the source of batch_id. It lacks an explicit when-not (e.g. 'use get_account_settings for current state, not batch history'), so it stops short of full alternative routing.

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?

Adds behavior the annotations cannot convey: the server executes the original request itself after confirmation so it must not be resent, pending requests expire after 24 hours, and the full status lifecycle is listed. This is exactly the context an agent needs to avoid duplicate calls and know when to stop polling.

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 dense sentences, front-loaded with the return shape and followed by operational guidance. The second sentence is long and bundles several concerns, but every clause carries real 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?

There is no output schema, yet the description covers the returned fields (status values, action summary, decision_via/decided_by/step_up, execution result), so an agent knows what to expect. Nothing needed 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 coverage is 100% and the single 'id' parameter is already documented as coming from error.approval_id. The description only reiterates the apr_ prefix and that the request belongs to this connection, adding marginal value over the schema.

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

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

States a specific verb and resource ('Returns one confirmation request ... by id (apr_...)') and enumerates the payload fields. No sibling tool does anything similar, so an agent can identify it immediately.

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

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

Explicitly scopes usage: 'Applies after a tool answered approval_required, polling about every 15 seconds until the status is final.' It gives the triggering condition, the polling cadence, and the terminal state, leaving nothing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful domain behavior beyond annotations: Cloud Patrol scans Threads every 15 minutes and replies to fresh posts through the official API, and it lists the status fields returned. It still lacks details such as auth requirements or rate limits, but the added context is meaningful.

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 three tight sentences and front-loads the return fields. The cadence sentence directly supports interpreting 'last scan time,' and the final sentence gives usage context. No sentence is wasted.

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

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

This is a simple read-only tool with one fully documented parameter, rich annotations, and no output schema. The description enumerates the returned configuration/status fields, explains Cloud Patrol behavior, and states when to call it, which is sufficient for an agent to invoke it correctly.

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

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

There is only one parameter, account_id, and schema description coverage is 100%, with the schema itself describing it as 'Account id.' The description references 'an account's' configuration but adds no format, constraints, or selection guidance for account_id. Baseline 3 is appropriate because the schema already carries the parameter documentation.

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

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

The description gives a specific verb and resource: 'Returns an account's cloud patrol configuration and status,' then enumerates fields like keywords, daily cap, replies sent today, review_before_reply, and last scan time. It clearly separates this from a settings mutation, but it does not explicitly contrast with nearby siblings such as cloud_patrol_log or cloud_patrol_stats.

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 use the tool: 'Applies before changing patrol settings or when the user asks whether patrol is on.' That is clear usage context. It does not name alternative tools like set_cloud_patrol, cloud_patrol_log, or cloud_patrol_stats, nor does it provide 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.

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

Annotations already cover read-only/idempotent safety, and the description adds real context beyond them: how the digest is consumed (appended by every generation path), and what has_material:false signals about fallback behavior. It stops short of describing payload size or shape, but that is a minor gap given no output schema exists.

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 sentences, front-loaded with the return content, followed by the flag semantics and the usage trigger. Dense but no filler; the parenthetical list is efficient rather than verbose.

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

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

With no output schema, the description does the work of explaining the return: digest contents plus the has_material flag. That is enough for an agent to call it correctly; only the absence of a pointer to build_material for the has_material:false case leaves a small 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?

There is one required parameter, account_id, fully documented in the schema (100% coverage). The description adds nothing about scoping or format for account_id, so the schema carries all semantic weight — baseline 3 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 ('Returns the account's material digest') and enumerates the digest contents (identity, claims, experiences, FAQ, sourced numbers, voice). It does not explicitly differentiate from the sibling build_material, so an agent must infer the read-vs-build distinction from the verb 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?

Gives a clear trigger: call it 'before generating when it is unclear whether the account has material.' It does not name the obvious alternative (build_material) or state when the digest is unnecessary, so routing is good but not exhaustive.

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, idempotentHint, and destructiveHint=false. The description adds useful behavioral context by listing exactly what is returned, including permission states (allow, ask, deny) and remaining quota information. It does not discuss authentication or rate limits beyond the returned counters, but with rich annotations this is a solid addition.

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

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

Two sentences, front-loaded with the return contents and followed by the operational triggers. Every clause carries useful information 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?

With no output schema, the description is responsible for explaining what comes back. It does so by enumerating the key returned items and even clarifies the permission value set. The annotations cover safety behavior, and the usage guidance covers when to invoke it.

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 baseline is 4. The description does not need to explain parameter semantics, and it appropriately focuses on return contents and usage triggers.

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

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

The description uses a specific verb ('Returns') and clearly enumerates the resources: plan, identity, permissions, remaining daily calls, patrol points, and connected accounts. It is distinguishable from most siblings, but it does not explicitly contrast itself with related tools like get_my_usage or list_accounts.

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 usage contexts: 'at the start of a session' and 'whenever a call answered approval_required or insufficient_scope.' This is strong guidance, though it does not state when to prefer other tools or any 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?

Annotations already establish the safe-read profile (readOnly, non-destructive, idempotent, closed-world), and the description adds real context beyond that: the Asia/Taipei day boundary, that days=1 means today since 00:00, the ordering (newest first), and cursor-based paging. It does not mention rate limits, retention, or behavior when no calls exist, which keeps it from 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?

The scope constraint and return shape are front-loaded, and parenthetical field lists pack a lot into a compact sentence pair with no filler. It is dense to the point of being slightly hard to scan, but nothing is redundant.

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 carries the return-value burden itself and does so fully: it names both result sections and their fields, the sort order, pagination mechanism, and record scoping. An agent can construct the call and interpret the response without further information.

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 earns an increment because it clarifies the timezone basis of the `days` window ("today since 00:00 Asia/Taipei"), which the schema's "1-30 (default 1 = today)" leaves ambiguous. `limit` and `cursor` are only restated, not elaborated.

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

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

Specific verb ("Returns") plus a precisely scoped resource ("this connection's own usage") and an enumeration of what comes back (summary: calls, units, errors, by_endpoint; recent calls: request_id, endpoint, status, units, at). "Only this connection's records" separates it cleanly from account-wide siblings like analytics_insights, cloud_patrol_stats, or list_events.

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

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

Explicitly states applicability: "when the user asks what this connection did, or a request_id is needed to report a problem." That is a concrete triggering condition rather than an implied one. It does not name a competing sibling or a when-not condition, so it stops short of 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?

The annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation, so the description needn't repeat safety traits. It adds useful behavioral context by summarizing the returned content and noting that it duplicates the initialize instructions, though it does not explicitly describe the response format.

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 tight sentences: the first states what is returned and its scope, the second identifies an alternative source, and the third gives usage conditions. It is front-loaded with zero waste.

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 explains what the return contains (daily loop, confirmation requests, quotas, review checklist). For a zero-parameter, read-only informational tool, nothing material 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?

The tool takes zero parameters, so the baseline is 4. The description correctly avoids parameter discussion, which is appropriate for a no-argument 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?

The description uses a specific verb and resource: 'Returns the operating playbook for running an account through this server.' It also enumerates the playbook's contents (daily loop, confirmation requests, quotas, review checklist), making its purpose unmistakable and distinct from every sibling tool.

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 the triggering conditions: 'Applies when the instructions were not kept or the user asks how the service works.' It also names the alternative source ('the same text is in the initialize instructions'), so the agent knows when this tool is redundant versus necessary.

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 already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered elsewhere. The description adds one genuinely useful behavioral fact — the returned id is the value to pass as account_id downstream — but says nothing about what fields come back per account (handle, username, avatar) or what an empty result means.

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 filler, and the core identity plus the account_id hand-off are stated before the applicability condition. Nothing in it repeats the title verbatim without adding 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?

There is no output schema, so the description carries the burden of explaining the return value; it discloses the id field but not the other likely fields the agent needs to match a username or description to an account. For a zero-parameter, low-risk list tool this is nearly sufficient, with that one 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 tool takes zero parameters, so the schema is complete and the description correctly adds no input coaching. Its mention of account_id describes output usage rather than input, which is a reasonable, non-redundant addition.

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

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

The description names a specific verb and resource (lists connected Threads accounts for this member) and clarifies its unique role: it is the source of the id that every other tool consumes as account_id. That separates it cleanly from settings-oriented siblings like list_account_settings or get_account_settings.

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 an explicit trigger condition — whenever an account id is needed and the user referred to an account by username or description — which is actionable guidance, not just a description. It does not name any when-not cases or an alternative tool, so it stops short of the top of the scale.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value on top: pagination behavior (up to 100 accounts per page), the presence of status chips such as expired authorization and repeated publish failures, and the columns/rules_url documentation returned alongside the data.

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 verb and resource, and every clause is informative, including the Traditional Chinese one-line summary. The long parenthetical enumeration of thirteen setting fields is verbose but earns most of its space by telling the agent what will be returned.

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 carries the return-value burden and does reasonably well by naming columns, rules_url, status chips and page size. Minor gaps remain: the overall response envelope (accounts array, next_cursor field name) is only implied.

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% and both parameters are documented there with their ranges and meaning. The description's "Up to 100 accounts per page, with limit and cursor for more" largely restates the schema rather than adding new semantics, so the baseline of 3 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: lists every connected Threads account of the member together with the bulk-settings-sheet fields and status chips. The scope is precise enough to separate it from single-account readers, but no sibling (e.g. get_account_settings_batch, list_accounts, preview_account_settings) is named, so the agent must infer the boundary.

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?

"Applies when the user wants to see or compare settings across many accounts" gives a clear selection context, which implicitly excludes single-account lookups. There is no explicit when-not statement or named alternative, so routing still relies on 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?

Annotations already declare a safe, read-only, idempotent operation. The description adds useful behavioral context: default 7-day window, newest-first ordering, limit range, and the meaning of since (only newer events) and types (filter by name). It does not cover pagination beyond the limit or return format, but the added context exceeds what annotations 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 a single, front-loaded sentence with no redundant or filler text. It efficiently packs default scope, ordering, event types, parameter semantics, and usage guidance into a compact form.

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 read-only list tool with full schema descriptions and annotations covering safety, the description provides all necessary context: what it returns, default window, ordering, event types, parameter effects, and when to use it. No output schema is needed for a straightforward list.

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 semantic meaning beyond the schema: since returns only events newer than the given timestamp, and types filters by event name. Limit range is also reiterated. This is modest but meaningful additional guidance.

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 ('Returns') and resource ('member's event feed'), defines the default scope (last 7 days, newest first), and enumerates the event types. It clearly distinguishes this tool from all siblings, none of which list event feeds.

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 when to use it: 'Applies when the user asks what happened recently or whether a post went out.' It also explains how the since and types parameters affect results. No when-not-to-use guidance or alternative tools are mentioned, but no direct sibling exists for this purpose.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the bar is lower. The description adds useful context by explaining the return payload (id plus short description) and that these are the formulas generate_posts accepts.

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

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

Two sentences, front-loaded with the resource and the relationship to generate_posts, then the usage condition. No wasted text.

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 input parameters and no output schema, the description supplies what is needed: the return shape (id + short description) and the routing condition. Nothing material 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?

The tool takes zero parameters, so the baseline is 4. There is nothing further for the description to clarify about parameters.

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

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

Names a specific verb and resource ('Lists the content formulas') and ties it directly to the consuming sibling, generate_posts. An agent can distinguish it from generate_posts itself 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?

States the condition for use ('when the user wants a specific structure... rather than auto') and gives concrete examples. It does not explicitly name when-not to call it beyond the 'rather than auto' contrast, but the routing intent 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?

Annotations already declare read-only/idempotent/non-destructive, and the description goes well beyond them: ordering, page-size bounds and default, the cursor mechanic, and a full enumeration of what each revision contains including the semantics of restore_body. That is exactly the kind of context annotations cannot 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?

Three compact clauses lead with purpose, then pagination, then payload, then applicability. Every sentence carries information; nothing restates the title or the annotations.

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

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

There is no output schema, but the description compensates by enumerating each returned field, including expected enum values for source. For a 3-parameter read tool with rich annotations, an agent has everything needed to call it and interpret the result.

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 baseline is 3; the description adds real value by tying limit/before to a coherent pagination story ('limit 1 to 50, default 20; before for the next page') and by naming the fields returned. Minor gap: no format example for the cursor value beyond the schema's 'next_before'.

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 ('Lists an account's guardrail revisions') plus ordering ('newest first'), which separates it cleanly from siblings like list_events, list_account_settings, and get_account_settings. An agent can identify it 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?

Explicitly gives the triggering conditions: the user asks what changed, who changed it, or wants to restore an earlier rule set. It does not explicitly name the write-side alternative (update_account_settings / revert_account_settings_batch) that would consume restore_body, so the routing is clear but not fully closed.

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 establish read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely non-obvious domain behavior beyond that: queued items publish automatically at schedule_times, and the caveat that a draft with held_reason publish_result_unknown and reclaimed:true may already be live on Threads — a real operational gotcha. It stops short of describing pagination or ordering guarantees.

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 sentences, front-loaded with the core action, then the behavioral nuance, then the triggering use case. Dense but every clause carries information; the held_reason sentence is slightly jargon-heavy but justified by the risk it flags.

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?

There is no output schema, and the description compensates by naming the return fields an agent needs (per-item position and next_publish_at). Combined with the annotation safety profile and full schema coverage, an agent has enough to call this correctly; ordering/pagination semantics remain unstated.

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 both the status enum values and the 'max 200' limit are already documented structurally; the description largely restates them. It does add meaning to status by explaining what 'queued' behaviorally implies (auto-publish at schedule_times) and what a 'draft' state can signify, which is a modest value-add over the schema.

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

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

Opens with a specific verb+resource+scope: 'Lists an account's library items by status', and enumerates the status values. It doesn't name a sibling to distinguish itself from (e.g. list_schedules, list_pending_replies, bulk_queue_library), so an agent must infer the boundary from the usage sentence rather than an explicit contrast.

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 final sentence gives concrete triggering conditions: 'what is queued, what is waiting as a draft, or what failed.' That is clear positive guidance with no exclusions or named alternatives, so it lands at 4 rather than 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?

Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower. The description adds real behavioral detail beyond them: the 24-hour expiry window and the contents of each draft (target post, drafted reply).

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 sentences, each carrying distinct information, with the core list operation stated first. No redundancy or 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?

No output schema exists, but the description sketches the returned records (target post, drafted reply, expiry), which is sufficient for an agent to know what to expect. A note on ordering or volume limits is the only minor 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?

Schema coverage is 100%, so both parameters are already documented, including the status values and pending default. The description repeats the same status vocabulary without adding constraints such as whether status filters can be combined.

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 (Lists) and resource (cloud patrol reply drafts) scoped to an account and filtered by status. The review-workflow framing separates it from the mutation siblings approve_pending_reply/reject_pending_reply, though those are not named 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?

Gives a clear triggering condition: 'Applies when review_before_reply is on and the user wants to decide what goes out.' It does not explicitly route to approve_pending_reply/reject_pending_reply once the user has looked, which would have closed the loop.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context by explaining held_reason semantics and giving example values such as content_rules_violated and publish_result_unknown.

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 focused sentences with the core listing behavior and use cases front-loaded. Every sentence contributes relevant selection or interpretation information without 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?

For a one-parameter, read-only listing tool with no output schema, the description is complete enough: it identifies the resource, optional filter, relevant returned fields, and the main user intents. Safety and idempotency are covered by annotations.

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 account_id parameter is already documented in the schema. The description repeats that filtering is optional but adds no syntax, format, or behavioral detail beyond the structured field.

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

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

The description uses a specific verb ("Lists") and resource ("scheduled posts"), states the optional account_id filter, and names returned fields including status, publish_at, and held_reason. It clearly distinguishes the operation from creation or cancellation siblings by framing it as a listing tool.

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 clear triggering contexts: "when the user asks what is coming up or why a post did not go out." It does not explicitly name alternative tools such as cancel_schedule or schedule_text, but the usage scenario is concrete enough for 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?

The description is consistent with readOnlyHint/destructiveHint=false and adds real behavior beyond the annotations: nothing is written, conflicts are refused when a cell changed since read, the preview_id expires in 15 minutes, and the result carries apply_changes. That is exactly the context an agent needs before chaining into the write tool.

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

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

Front-loaded with the no-write guarantee and output shape, then input modes, then the handoff to apply_account_settings; each clause carries distinct information. Even the 繁中 line is a single compact sentence rather than a full duplicate.

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 still explains what the result contains (per-cell values, warnings, row errors, apply_changes, preview_id) and its lifetime. Input format, limits, and the downstream call are all covered, leaving no gap for a two-parameter preview tool.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning: the two input modes (changes list vs. csv) and that the csv mirrors the website download format, plus the base-versus-current conflict rule. The 100-item cap and column rules stay in the schema rather than being reiterated.

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 ('Shows what a batch of settings changes would do and writes nothing') and enumerates the returned per-cell old/new values, warnings, and row errors. It is clearly distinguishable from its write sibling apply_account_settings, which it names 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?

'Applies before any bulk change, so the user sees the exact cells first' gives a concrete usage rule, and the preview_id handoff to apply_account_settings makes the sequence explicit. It never states when NOT to use it, e.g., a single-account edit that should go through update_account_settings.

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?

Goes well beyond the annotations: discloses 500-character auto-threading, the 30-minute boundary that selects between publish-now and schedule permissions, the possibility of blocking on owner confirmation when the connection is set to "ask", and idempotency_key retry behavior. The idempotentHint=false annotation is not contradicted — the description explains how to opt into idempotency per-request rather than claiming the tool is idempotent by 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 with the action and mode, then media shapes, then threading, then the permission/confirmation model, then the usage trigger. Five dense sentences with no filler; the long permission sentence carries information an agent cannot get from 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?

For a 7-parameter open-world mutation with no output schema, it covers modes, media, permissions, approval gating, and retry safety. It stops short of describing what comes back (post id, scheduled job id) or what happens on validation failure, which matters given there is no output schema to lean on.

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, but the description adds real semantics: media_urls count maps to image vs carousel (2–10), video_url is the mutually exclusive alternative, publish_at is "ISO 8601 with offset", and publish_now versus publish_at is an either/or. Only account_id and idempotency_key remain thin.

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 (publishes) and resource (a post to Threads) plus the two modes (now via publish_now, later via publish_at). It does not explicitly name the sibling `schedule_text`, which is the nearest-looking alternative, so an agent must infer the boundary from the "final text" phrasing.

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?

"Applies when the user has final text and wants it on Threads" gives a clear triggering condition and implicitly rules out draft/generation flows (generate_posts, build_material). No explicit exclusion versus `schedule_text` or pointer to `cancel_schedule`/`list_schedules` for the inverse operation, so the routing guidance is clear but not complete.

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 flag destructive=true and idempotent=true, but the description adds real substance: the draft is "never sent" and "the same post is not proposed again," clarifying the irreversible downstream consequence of the destructive hint. Missing only auth or return-value detail, which the annotations partly cover.

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, front-loaded with the action and scoped by id, then behavior, then the usage condition. No wasted text.

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 single-record mutation with full schema coverage and annotations carrying the safety profile, this covers action, side effects, and trigger sufficiently. Auth requirements and output (none) are not discussed, a minor 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?

Schema description coverage is 100% (id and reason already documented), so the baseline is 3. The description restates "by id with an optional note" but adds no syntax or format guidance beyond the schema.

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

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

States a specific verb (Rejects) and resource (one drafted cloud patrol reply), scoped by id with an optional note. An agent can distinguish it from approve_pending_reply by the verb, though the sibling is not named 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?

"Applies when the user does not want a drafted reply to go out" gives a clear trigger condition. It stops short of explicitly contrasting with approve_pending_reply or noting prerequisites, but the when-to-use context is solid.

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 flag destructive=true and idempotent=false, and the description goes well beyond them: it discloses the 24-hour revert window, skip-with-reason behavior for accounts edited after the batch, the no-overwrite guarantee, and the one-revert-per-batch limit. Those are exactly the side effects and failure modes an agent needs before invoking a destructive tool.

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

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

The core semantics are front-loaded in the first two sentences, with the usage trigger third and the localized copy last. Every sentence contributes a distinct constraint (time window, skip rule, one-shot limit, trigger), with no filler.

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

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

With one required parameter, rich annotations, and no output schema, the definition still covers the return-relevant behavior (skipped accounts listed with a reason) and all hard limits. An agent has everything needed to call it correctly and set user expectations.

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

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

There is a single parameter with 100% schema description coverage, and the schema already states "batch_id from apply_account_settings." The description adds no syntax, format, or sourcing detail for batch_id, so the baseline 3 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?

"Restores the values that one batch changed, within 24 hours" states a specific verb (restore) and resource (a batch's prior values) with a precise scope. The operation is inherently distinguishable from apply_account_settings and update_account_settings, though no sibling is named explicitly, which keeps 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?

"Applies when the user wants to undo a bulk change" gives an explicit usage trigger, and the 24-hour window plus once-per-batch limit act as effective exclusion conditions. It never names an alternative tool (e.g. update_account_settings for targeted fixes), so it stops at 4.

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?

Goes well beyond the annotations by disclosing content_rules validation, the 422 + no-schedule outcome under enforce:block, and a re-check immediately before publishing. It does not address the idempotentHint=false risk (e.g., duplicate schedules) or explain what 'existing text' refers to, leaving some behavioral gaps for a destructive, open-world mutation.

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

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

Three dense sentences, front-loaded with the primary action and time-selection logic, with validation caveats after. Some clauses (parenthetical mutual exclusion, re-check timing) are compressed almost to the point of ambiguity, but nothing is wasted.

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

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

For a 5-parameter mutation with no output schema, the description covers the scheduling mode, validation failure behavior, and character limit, which is most of what an agent needs before calling. Still missing what the call returns (schedule identifier) and how to inspect or cancel the resulting schedule, and the destructiveHint=true framing is never explained.

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, but the description adds two facts the schema lacks: the 500-character cap on text and the mutual exclusivity rule linking publish_at and auto_optimize_time. It omits the deprecated schedule_at alias, though the schema already flags that.

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 ('Schedules an existing text') and bounds scope with the character limit and the two time-selection modes. It does not distinguish itself from close siblings such as publish or list_schedules, so an agent must still infer which scheduling entry point applies, but the core purpose 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 closing sentence explicitly scopes applicability: 'text-only posts with a specific time or when the user wants the system to pick the time,' and the mutual exclusivity of publish_at vs auto_optimize_time is spelled out. There is no explicit when-not or named alternative tool, which keeps it short of 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?

Goes well beyond the destructive/idempotent/openWorld annotations: 15-minute polling of fresh Threads posts via the official API, one patrol point consumed per delivered reply, the review_before_reply hold-in-list_pending_replies behavior, and the permission gating. That is exactly the operational context an agent needs before mutating this resource.

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

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

Dense but organized: configurable fields first, then runtime behavior, then permission constraint, then the user-intent trigger. It is a single long block and some tier detail repeats the schema, but no sentence is 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?

Covers purpose, behavior, permission prereqs and the review loop, with no output schema to explain. The remaining gap is update semantics (partial merge vs full replace) and what the call returns, which an agent would reasonably want for a destructive upsert.

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 baseline is 3; the description still adds value by tying review_before_reply to list_pending_replies and explaining what daily_cap consumes and what the plan tiers mean in practice. It does not clarify whether omitted fields are preserved or reset, which matters for a set-style upsert.

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

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

Specific verb pair ('creates or updates') plus resource ('an account's cloud patrol') and an enumeration of the configurable surface (keywords, persona, daily_cap, enabled, review_before_reply). It does not explicitly name get_cloud_patrol as its read counterpart, so sibling 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?

Gives an explicit when-to-use clause ('stop patrol or tune its keywords, persona and cap while it is off') and a hard when-not: turning patrol on or editing an enabled patrol requires the patrol permission, which directory connections lack, so the owner must do it in MindThread. It also routes review-mode drafts to list_pending_replies.

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

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

Annotations only flag the tool as destructive, non-read-only and idempotent; the description adds substantial context beyond that: partial-update semantics ('Only the fields sent are changed'), the exception that content_rules is replaced wholesale, 412 behavior on if_match mismatch, reason being persisted into the revision, dry_run writing nothing, and that loosening a guardrail may block on owner confirmation. These are exactly the side effects an agent cannot get from the structured fields.

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 opening sentence is a single run-on enumeration of every parameter and every content_rules sub-key, almost all of which is already in the schema at 100% coverage, so that bulk does not earn its place. The behavioral sentences that follow (dry_run, if_match, guardrail confirmation) are the valuable part and are appropriately placed, but the structure would be stronger if the field inventory were trimmed.

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

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

For a 12-parameter, nested, destructive mutation with no output schema, this covers the hard parts: merge semantics, guardrail approval gating, preview mode, optimistic concurrency and the 412 response. Minor gaps remain — no pointer to preview_account_settings as the non-writing alternative or to revert_account_settings_batch for undoing a bad change — but an agent has enough to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns more by explaining semantics the schema does not: whole-replacement of content_rules versus per-field merge for everything else, the concurrency contract behind if_match (412 rather than overwrite), and the audit role of reason. It re-lists field names and limits that the schema already documents, which dilutes the added value slightly.

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?

Opens with a specific verb+resource ('Changes an account's ...') and enumerates the exact mutable fields, so the agent knows precisely what domain this touches. It only partly differentiates from siblings: it references get_account_settings for the etag but never contrasts with apply_account_settings or preview_account_settings, which overlap heavily.

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 closing sentence gives an explicit trigger ('Applies when the user asks to change voice, posting times, review mode, auto-reply or content rules'), which is a genuine when-to-use statement. It stops short of stating when NOT to use it or naming the alternative tools (apply_account_settings, preview_account_settings) that an agent would otherwise have to infer from the sibling list.

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 annotations, it discloses meaningful behavioral details: text is checked against content_rules, and it explains three distinct 409 failure modes with their meanings. This tells an agent how the operation can fail and what conflicting states indicate, which 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 front-loaded and dense with useful information, with no filler. The semicolon-heavy error-code sentence is slightly packed, but every clause 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 five-parameter mutation tool with annotations and no output schema, the description is largely complete: it covers the mutation, validation, conflict errors, and usage context. It omits success-result shape and does not clarify that supplying only id is unlikely to change anything.

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, but the description adds real meaning by enumerating status values, clarifying that text is validated against content_rules, and distinguishing explicit order from first/last position. It does not explain whether fields can be combined or whether at least one optional field must be supplied.

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, then enumerates the exact mutable fields: status, text, and queue position/order. It also distinguishes this single-item operation from bulk siblings by repeatedly scoping it to 'one library item' and 'one item'.

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 clear usage context: edit, reorder, archive, or restore one item. However, it does not explicitly name alternatives such as bulk_archive_library or bulk_queue_library, nor does it state when not to use this tool; the one-item scope only implicitly routes multi-item work elsewhere.

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