Read the connected TikTok creator’s posting options

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

Annotations already cover readOnlyHint=true and destructiveHint=false, lowering the bar. The description adds genuinely useful behavioral context beyond that: TikTok's requirement that actual options be shown and a privacy level picked (never assumed or defaulted), the account-dependence of the returned values, and the dependency on TikTok being connected. It also discloses that the same privacy levels apply to photo posts. No contradiction with annotations.

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

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

The purpose is front-loaded in the first clause, and every subsequent sentence earns its place: the required user-interaction behavior, the sequencing, the photo-post edge case, and the connection prerequisite. It is longer than the minimal definition, but the density is justified because each sentence conveys a distinct operational fact rather than 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?

With no output schema present, the description responsibly enumerates the return values (privacy levels, comments/duet/stitch, video length, nickname), covers the required pre-condition (TikTok connected via Settings ▸ Connectors), explains the follow-on step, and flags the non-obvious slideshow case. Minor gaps remain around exact return formatting and error behavior for a disconnected account, but against the sibling set this is well 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?

The tool has 0 parameters and an empty schema at 100% coverage, so the description carries no parameter burden — the baseline of 4 applies. There is nothing for the description to explain regarding inputs. This is correct and needs no additional param 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 opens with a specific verb+resource: 'Read the connected TikTok creator's REAL posting options BEFORE posting.' It enumerates exactly what is returned (privacy levels, comments/duet/stitch availability, max video length, nickname), which separates it from siblings like post_to_tiktok, tiktok_account_status, and list_tiktok_videos. The 'REAL' emphasis makes clear this returns account-specific options rather than generic defaults.

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 an explicit operation order: 'Call this first, show the options, get the user's pick, then call post_to_tiktok.' It also states the tool must run 'BEFORE posting.' This is strong sequencing guidance. It lacks explicit when-not-to-use phrasing or named alternatives, but the mandated 'call this first' ordering effectively distinguishes it from post_to_tiktok, so only the absence of explicit exclusions keeps it from a 5.

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