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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond annotations: the returned permissions are dynamic and can change when the creator toggles account privacy, and the privacy level must come from this exact list. This is useful, non-obvious behavior.

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 sentences long, front-loads the core purpose, and gives the critical usage directive immediately. Every sentence adds value: what is returned, when to call it, and why the returned value is required. No wasted words.

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 tool with one optional parameter, no nested objects, and no output schema, this description is complete. It states what data is returned, which post operations depend on it, and why it may change. An agent has everything it needs to call the tool 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 optional parameter, and the schema description covers 100% of it, including how to list accounts. Per the baseline rule, a high schema coverage means the description need not repeat parameter details. The description adds no direct parameter semantics, but it does not need to.

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 exactly what the tool returns: available privacy levels, comment/duet/stitch toggles, and maximum upload duration. Although the tool name is generic ('get_creator_info'), the title and description make the specific resource—posting permissions—unmistakable and distinct from sibling tools like get_profile.

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

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

The description gives explicit, actionable guidance: 'Call this before post_video or post_photos.' It also explains the critical dependency—TikTok requires the privacy level to come from the returned list—and warns that the value changes when the account flips private. This leaves no ambiguity about when to invoke it.

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 adds valuable behavioral details beyond the annotations, such as the possible statuses and the specific nuance that an empty post_id on PUBLISH_COMPLETE is normal due to moderation delays. This explains expected non-error behavior and the fail_reason field, which is critical for correct interpretation. It does not contradict any 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 description is a single, well-structured paragraph that front-loads the purpose immediately and then adds necessary status explanations and the moderation caveat. There is no filler; 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 tool with only two parameters and no output schema, the description covers the essential behavioral aspects: statuses, failure reason, and the moderation edge case. It does not detail the exact response structure, but given the simplicity and the annotations, it is sufficiently complete. A slightly more explicit mention of what the response contains would push it to a 5.

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% (both parameters have descriptions), so the baseline is 3. The description does not add extra meaning beyond the schema, although it reinforces that publish_id is the one returned at creation, which matches the schema. No additional parameter-level guidance is needed.

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

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

The description clearly states the tool's purpose: tracking the status of a post created by post_video, post_photos, or the drafts tools. It names the specific resource (a post by its publish_id) and distinguishes it from siblings like list_videos or post_video by focusing on status tracking of a known post.

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 to use this tool for posts created by specific creation tools, which gives clear usage context. It does not explicitly mention when not to use it or name alternatives, but the intended scenario is unambiguous. Sibling tools like list_videos serve a different purpose, so the guidance is adequate.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond that by disclosing the API's hard limitation that only the connected account's profile is accessible, which is essential behavioral context for an agent deciding whether this tool can satisfy a request.

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 sentences with no filler. It front-loads the useful field list and ends with a crucial scope limitation, making every sentence informative and 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 simple read-only tool with no required parameters and a fully documented schema, the description is sufficiently complete. It enumerates the returned data, clarifies the account scope, and works alongside annotations that already communicate safety. No critical information is missing for an agent to call this tool 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?

The single parameter 'account' is already fully described in the schema, including its default behavior and guidance to use list_accounts to discover valid values. The description does not need to restate this, so the schema carries the semantic load; the description adds no new parameter-level 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?

The description identifies a specific verb and resource: reading the connected account's profile and audience. It also lists concrete fields (username, display name, bio, verified flag, follower/following counts, total likes, public video count), making the tool's purpose unmistakable. The final constraint about only seeing the connected account distinguishes it from sibling tools that access other data.

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

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

The description provides clear context: this tool targets the connected account's profile and explicitly warns that it cannot read anybody else's profile. It does not name a specific alternative tool for other profiles, but the boundary for when to use this tool is clear from the API limitation statement.

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, and destructiveHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: the cover URL expiration (6 hours) and that a 404'd cover requires this call. This is a non-obvious behavioral trait that aids the agent in troubleshooting. It does not contradict 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 description is two sentences: the first states the core function, the second adds a specific use case (cover refresh). No filler, front-loaded with the primary action. Every word earns its place, and the structure is clear and scannable.

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 fetch-by-id tool with no output schema, the description covers the key operational aspects: the maximum count (20), the fact it returns full stats, and the refresh use case. It does not describe the exact return format, but that is acceptable given the tool's simplicity and existing annotations. It is complete enough for an agent to call correctly.

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

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

Schema description coverage is 100%: both video_ids and account are described. The description does not add parameter-specific meaning beyond the schema; it mentions 'full stats' as a return property but not tied to parameters. The baseline of 3 applies because the schema already documents parameters adequately.

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 precise action ('Fetch up to 20 of your videos by id, with full stats') with a specific resource (videos) and selection criterion (by id). It clearly distinguishes from siblings like list_videos (which would list all) and search_my_videos (which searches by query). The title reinforces the purpose, and the description adds the crucial limit of 20, already present in schema, but stated clearly.

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 use case: refreshing cover_image_url because those links expire after 6 hours, and the cover 404s needs this call. This implies when to use it over a cached URL. However, it does not explicitly contrast with alternative tools like list_videos or search_my_videos, and does not state when not to use it. The usage guidance is strong for the specific scenario but not comprehensive.

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 adds a non-obvious behavioral trait beyond the annotations: this tool does not call TikTok at all, so it succeeds even when a token has expired. This meaningfully informs the agent about network dependency and failure modes. Annotations already cover read-only and idempotent safety, so the description's extra context earns credit.

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 tightly written sentences deliver the core purpose, the practical use of the result, and a key behavioral guarantee. There is no filler or redundancy.

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

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

Given the tool's simplicity, empty schema, and strong annotations, the description covers everything an agent needs: what the tool returns, how to use the result, and an important edge-case behavior. No output schema exists, but the description states the essential return semantics.

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 and the schema already defines an empty object, so there is nothing for the description to add. The description still clarifies what the returned value serves as (`account` on other tools), which is useful semantic context for an otherwise parameterless call.

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 identifies the resource: all TikTok accounts the server can act as, and distinguishes this from sibling tools by stating these account names are the values to pass as `account` elsewhere. The purpose is specific and immediately actionable.

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 context for when to call this tool: when you need the canonical account identifiers to use with any other tool. It also notes that it works even with an expired token, implying it is safe to use as a fallback or first step, though it does not explicitly list exclusions or alternatives.

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

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

Beyond the readOnlyHint annotation, the description discloses automatic pagination past TikTok's 20-per-page limit, newest-first ordering, and an API limitation that private/draft videos are inaccessible. This gives an agent useful expectations about scope and behavior that are not visible from annotations alone.

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 no filler: the core output and ordering are front-loaded, followed by pagination and visibility caveats. Every sentence contributes information beyond the tool's 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?

For a read-only list tool, the description covers what is returned, ordering, pagination, and visibility limits, while the schema covers all parameters. It is slightly incomplete on sibling differentiation—there is no guidance for choosing among get_videos, top_videos, or search_my_videos—but the invocation context is otherwise sufficient.

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 description itself adds no parameter-level explanation, but the input schema covers all three parameters (limit, cursor, account) with 100% coverage, including the milliseconds-vs-seconds warning and default account behavior. Since the schema carries the semantic load, the description does not need to compensate.

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 ('list') and resource ('your public TikTok posts'), and states the returned metrics (views, likes, comments, shares, engagement rate) and ordering ('newest first'). It is clear but does not explicitly distinguish itself from sibling tools such as get_videos or top_videos.

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

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

The description implies usage context by specifying what the tool returns and its ordering, and it gives a clear exclusion: 'Only public posts appear: TikTok's API cannot see private or draft videos.' However, it never names alternatives like get_videos or search_my_videos, so there is no explicit when-to-use-this-vs-that 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 declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds the polling workflow (returns publish_id, poll get_post_status) and cross-references domain rules from post_video, which is useful behavioral context beyond the annotations. 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 description is three short sentences that lead with the core purpose, then the critical post-call step (polling), and finally a cross-reference to existing rules. Every sentence earns its place; there is no fluff or repetition.

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

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

For a tool with 12 parameters and no output schema, the description is surprisingly complete: it states the action, the limit, the domain requirement, and the follow-up polling step. It omits the confirm requirement and public-moderation behavior, but those are explicitly covered in the parameter descriptions. The agent gets enough to call it correctly without ambiguity.

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 high (83%), so the parameters are already well-documented. The description adds minimal parameter-specific details beyond the schema, such as the 35-image limit (already in maxItems) and public URL requirement (already in photo_urls description). It does not compensate for the remaining uncovered parameters, but with high coverage, baseline 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?

The description opens with a specific verb and resource: 'Publish a photo carousel' with a clear constraint of up to 35 images and from public URLs. It distinguishes itself from siblings like post_video by focusing on photos and mentions the return of a publish_id, making the tool's purpose unambiguous.

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

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

The description provides clear context for using the tool: it publishes a photo carousel and instructs to poll get_post_status. It references post_video for domain-verification rules, but does not explicitly compare against alternatives like send_photos_to_drafts. This is clear enough for an agent to infer live publishing vs. drafting, but lacks explicit exclusions, so not 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 description adds significant behavioral detail beyond the annotations: the call returns as soon as TikTok accepts the job, long before the post is live, and unaudited apps always produce private posts regardless of the privacy_level argument. It also explains the need to poll get_post_status. These are exactly the kind of non-obvious behaviors an agent needs to know.

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 carry the core purpose, the async behavior, and the privacy caveat. The most important facts are front-loaded with no filler. 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 tool with 12 parameters, no output schema, and multiple sibling tools, the description covers the essential runtime behavior: what is returned, how to track the post, and the unaudited-app privacy quirk. It does not mention the required confirm parameter, but that is fully documented in the schema, so this is a minor gap overall.

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

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

The input schema already documents 75% of the parameters, so the heavy lifting is done there. The description adds extra value for privacy_level by warning that unaudited apps override whatever value is passed, making every post private. This is a meaningful parameter-related caveat 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?

The description clearly identifies a specific verb and resource: 'Publish a video straight to the account from a public URL.' It also communicates the key output, publish_id. However, it does not explicitly distinguish itself from sibling tools like post_photos or send_video_to_drafts, so the differentiation is implicit.

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 context for what the tool does and tells the agent to poll get_post_status afterward, which is useful. It does not, however, state when to prefer this over alternatives such as send_video_to_drafts or post_photos, nor does it explain when not to use it. Usage is implied by the purpose rather than explicitly 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 mark this destructive and not read-only. The description adds useful non-obvious behavior: the refresh token stops working immediately and restoration requires re-running `tiktok-mcp auth`. That goes beyond the annotation hints, though it does not detail the exact response or further side effects.

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

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

Two sentences carry the essential action and consequence with no filler. The destructive effect is front-loaded, and the recovery command is a useful close.

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

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

The core effect and recovery path are covered, and the annotation hints supply the destructive safety signal. However, with no output schema, the agent is not told what a successful revocation returns, and the misleading confirm description leaves a required confirmation ambiguous. A short note on expected response or error conditions would complete 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 account parameter is well documented (named account, default to first, call list_accounts). However, the confirm parameter's description appears copied from a deletion/post tool: it talks about a TikTok post being public and deletion not removing it from feeds, which does not explain what 'confirm' means for revoking access. With 100% schema coverage this misleading text is worse than no description at all, and the tool description does not compensate.

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: it 'hands the token back to TikTok' and 'removes your app from the account's connected-apps list.' This clearly distinguishes revoke_access from sibling tools like list_accounts, get_profile, or post_video.

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 makes the context clear: it is used to disconnect an account and immediately invalidates the refresh token, and it tells the agent how access can be restored by re-running `tiktok-mcp auth`. It does not explicitly name alternatives or when-not conditions, so it stops short of full guidance.

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

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

Beyond the readOnly/idempotent annotations, the description discloses a crucial behavioral caveat: a miss means the item is not in the last `scan` videos, not that it does not exist. It also reveals the local-filtering implementation, which helps an agent set expectations about completeness.

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 short sentences with no filler. The action is front-loaded, followed by a brief implementation rationale and a vital caveat, so 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 simple read-only search tool with fully documented parameters, the description covers purpose, local filtering behavior, and the open-world miss semantics. The annotations already provide the safety profile, and no output schema is needed to understand that this returns matching posts.

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

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

The input schema already covers all parameters at 100% coverage, so the baseline is 3. The description adds extra meaning by tying `scan` directly to the miss semantics, clarifying that the search scope is limited to the most recent `scan` videos. It does not repeat schema details unnecessarily.

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: 'Find your posts whose title or description matches a query.' It also distinguishes itself from sibling list/get tools by explaining that TikTok has no native library search, so this tool pages recent videos and filters locally.

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 context for when this tool is appropriate: there is no TikTok-side search over your own library, so the tool compensates by scanning recent videos locally. It does not explicitly name alternatives such as list_videos, but the intended use case is evident.

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, idempotency, and destructiveness, so the description only needs to add context. It adds useful behavioral facts: the creator must finish in the app, the request needs only the video.upload permission, and TikTok rejects the request if the app version is below 31.8. This is meaningful and goes beyond what annotations and schema 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 three short sentences with no filler. The core action is front-loaded, followed by the permission requirement and the version constraint, each of which earns its place. It is easy to scan and directly actionable.

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

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

The description is adequate for understanding the basic operation and key constraints, but it leaves gaps because there is no output schema and no explanation of parameter meaning or async/result behavior. An agent can probably invoke it correctly but may not know how to interpret the response or how it relates to send_video_to_drafts and post_photos.

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 only 20%, with only the account parameter described. The description does not explain photo_urls requirements, photo_cover_index semantics, or how title and description are used. Because the schema leaves most parameters undocumented and the description does not compensate, an agent has to guess about important invocation details.

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 action, resource, and destination: send photos to the TikTok inbox for the creator to complete. The phrase 'for the creator to finish in the app' also distinguishes this from direct publishing, and the photo focus separates it from send_video_to_drafts. The title reinforces the photo-carousel scope without adding misleading information.

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

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

The description implies the tool is for preparing photo content as drafts rather than publishing it, and it gives valuable prerequisites such as the video.upload permission and TikTok app version 31.8+. However, it never explicitly names alternatives like send_video_to_drafts or post_photos, nor does it state when not to use this tool.

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, the description reveals meaningful behavioral details: the creator receives a notification, nothing goes public, the auth scope is only video.upload, and TikTok enforces a 5-draft-per-24-hour limit. These are exactly the kind of side-effect, permission, and rate-limit facts that help an agent predict tool behavior. It does not contradict the readOnlyHint=false, idempotentHint=true, or destructiveHint=false annotations.

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

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

Three sentences, each earning its place: core behavior first, then the notification/privacy consequence, then the auth and quota constraints. No filler or repetition of schema details. It is front-loaded and efficiently structured.

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

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

The description covers purpose, auth needs, quota, URL verification, and the draft-not-public outcome, which is nearly complete for a two-parameter tool. The only notable gap is that it does not describe the API response or what happens when the 24-hour draft limit is exceeded. Still, an agent has enough to select and 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?

Schema description coverage is 100%, and both parameters have thorough descriptions in the schema, so the tool description does not need to repeat them. The description's reference to video.upload is a permission scope, not parameter-level semantics. The schema carries the burden adequately, so a baseline 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?

The description opens with the specific action: 'Send a video to the account's TikTok inbox instead of publishing it.' This clearly identifies the verb, resource, and a distinctive contrast to publishing, which separates it from siblings like post_video. The 'so nothing goes public without them' detail reinforces exactly what this tool achieves.

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 concrete usage context: this is 'the path that works before your app passes the Content Posting audit' and requires only video.upload. The 'instead of publishing it' phrasing implies the alternative is a publishing tool, but it never explicitly names post_video or states when not to use this tool. Strong context, but the alternative is not made fully explicit.

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, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it explains the statistical skew (one viral post drags the mean) and implicitly indicates the tool computes aggregate analytics rather than raw data. This extra guidance raises it above baseline, but it doesn't describe return format or error behavior, so a 4 is appropriate.

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 with zero waste. The first sentence front-loads the aggregate metrics and scope ('recent posts'), and the second gives both an alternative and a statistical caveat. Every word earns its place, and the most important usage guidance appears early.

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

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

The tool has no output schema, but the description enumerates the exact metrics it returns, effectively serving as the output spec. It also covers usage guidance and statistical interpretation. Given annotations already handle the safety profile, and the description is sufficient for an agent to know what it will get, only minor gaps remain (e.g., explicit return structure or default account behavior, which is in the schema). This is reasonably complete.

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% – both `scan` and `account` have complete descriptions. The description mentions 'recent posts' which loosely relates to `scan`, but it adds no additional parameter syntax or format details beyond what the schema provides. With full schema coverage, the baseline of 3 is correct; the description does not enhance parameter understanding.

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

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

The description clearly states the tool aggregates stats over recent posts and enumerates the specific metrics (total/mean views, median/90th percentile, engagement rate, posting interval). It explicitly contrasts with listing videos, distinguishing it from sibling tools like list_videos. This is a specific verb+resource with clear scope.

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

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

The description explicitly says 'Reach for this instead of listing videos and adding them up,' naming the alternative and the condition that selects this tool. It also provides statistical guidance (read the median rather than the mean), giving the agent concrete direction on how to interpret results. This fully covers when-to-use vs alternatives.

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 readOnly/idempotent/destructive annotations, the description discloses non-obvious behavior: TikTok has no ranked endpoint, ranking is done locally after pagination, and anything older than scan cannot appear. This adds real behavioral context an agent would otherwise not know.

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 with no filler. The value proposition is front-loaded, the key limitation is stated early, and the alternative-use guidance is packed into one tight sentence.

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 rich annotations, full schema coverage, and clear usage guidance, the description covers the main caveat and selection criteria. There is no output schema, but the return type (ranked videos) is inferable from the title and limit parameter, so nothing critical 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 input schema already covers all four parameters with 100% coverage, so the baseline is 3. The description adds meaningful interpretive value for `scan` ('how far back it looks, and anything older than that cannot win'), which justifies a slightly higher score; limit/metric/account are left to 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?

The description states a specific task—'Your best posts, ranked'—and explains that it pages recent videos and sorts them locally. It also explicitly contrasts itself with list_videos, making its distinct purpose immediately clear.

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, actionable guidance: use this rather than calling list_videos and sorting in context, and explains why ('spends the whole window on videos you discard'). The scan-bound caveat further clarifies when this tool is appropriate.

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