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

The annotations already carry readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the 'read-only: returns public data and changes nothing' sentence largely restates them. The genuine additions beyond structured data are the billing disclosure ('Costs 1 credit per request') and the note that only public data is returned, which hints at private/deleted-post failures. It stops short of stating what happens on a nonexistent or private ID.

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 payload enumeration is front-loaded and the cost is stated up front rather than buried, which is the right ordering. The middle 'Read-only' sentence duplicates the annotations and could be dropped without loss, so it is not perfectly waste-free.

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 field enumeration does the work of telling the agent what it will receive, and the credit cost covers the operational concern. For a single-parameter read tool this is close to sufficient; only failure behavior for private, deleted or region-blocked posts is left unaddressed.

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 schema property already documents both accepted forms (bare ID or full post URL) with examples. The description adds no further format, encoding or validation guidance for videoId, so the schema carries this dimension entirely.

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 ('Get a TikTok video or photo post by ID') and enumerates the payload (caption, counts, creator, sound, hashtags, mentions, place, cover image, subtitle files). That detail is enough to separate it from tiktok_search_videos (discovery) and tiktok_get_user_posts (enumerating a creator's feed) 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?

The 'by ID' framing implies you must already hold a post identifier and that search tools are needed to find one, but no sibling is named and no when-not condition is given (e.g. use tiktok_get_related_videos or tiktok_search_videos instead when you lack an ID). Usage is inferable rather than stated.

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