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

With no annotations, the description carries the full behavioral burden and does so: a real browser window pops up, auto-closes about 2s after a successful scan, self-closes after at most 2 minutes if unscanned, and wait_seconds timeouts do not abort the background session. It also discloses the anti-automation and SMS-verification constraints and the verify_code.txt workaround.

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 window behavior and timeout semantics that govern how to call it, and nearly every sentence adds operational value. Minor redundancy with the schema's headed description and slightly dense bolding keep it from a 5.

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 describing the return states ('scan succeeded' vs 'session still waiting for scan'), window lifetime, and the SMS-verification recovery path. An agent has everything needed to invoke, poll, and recover.

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 nevertheless adds meaning by explaining that wait_seconds' timeout does not interrupt login and that the session keeps waiting in the background, plus the polling consequence. headed is only restated, so it is not a full 5.

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: logging a user into Douyin via QR scan. The scope (per-account login, distinct from status/logout siblings) is unambiguous, and an agent can tell it is the credential-establishing tool rather than a read or query 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?

Explicitly tells the agent to re-call this same tool when the session is still waiting rather than starting a new login, and gives the condition for setting headed=false (only on CI/servers with no desktop session). It also routes SMS-verification retries through verify_code.txt, which is real alternative-path 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?

With no annotations, the description carries the full burden and does so richly: it names the exact file affected, its role as the login credential, the irreversible effect (account returns to logged-out), and explicitly scopes out collateral damage (project dir, materials, published works unaffected). This is exactly the behavioral context an agent needs before triggering a destructive confirmation flow.

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 core action and outcome, then the workflow, then the scope caveat. Dense but every clause carries operational weight; the ★ markers aid scanning. Slightly long, but justified by the destructive nature of the operation.

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, no-output-schema, no-annotation tool, the description covers effect, confirmation discipline, post-condition, and non-effects — everything needed to invoke it 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?

Schema coverage is 100%, so both params are already documented, giving a baseline of 3. The description adds real semantics beyond the schema by defining confirm's role as a two-phase safety gate rather than a plain boolean.

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 (重置某账号登录态) and immediately clarifies the exact mechanism: deleting a single cookies file, not uninstalling. It also distinguishes itself from account_login/account_status by describing the resulting state and the 'logout not uninstall' 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?

Explicitly prescribes the two-step workflow: with no confirm it only reports the intended path (dry run), and confirm=true may only be passed after the user explicitly agrees. It further gives the follow-up condition (must re-scan QR before publishing), 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?

With no annotations, the description carries the burden and does disclose that this reads local cookie validity state in social-auto-upload, implying a non-mutating local check. It stops short of stating side effects, failure behavior, or what an invalid result looks like.

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 core purpose before the usage hint and the parameter caveat. No redundant restatement of the tool name; tight and appropriately sized.

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 tool with no annotations, the description covers purpose, timing, and parameter identity well, but there is no output schema and the description never says what the check returns (boolean, expiry, error shape). That leaves a small but real gap for an agent deciding how to consume 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 the baseline is 3, but the description adds a genuine disambiguation the schema lacks: account is the login name used in social-auto-upload, NOT the Douyin nickname. That extra meaning reduces a real selection error.

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 (查询/query) and resource (抖音账号登录态), and clarifies the mechanism (本地 cookie 是否还有效 in social-auto-upload). An agent can distinguish it from douyin_account_login/logout/publish 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 a clear trigger: check before publishing or logging in to avoid discovering mid-way that you're not logged in. There is no explicit exclusion list or naming of a sibling alternative, but the when-to-use context 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?

No annotations are provided, so the description carries the full burden. The verb '看' and 'info + work list' make clear this is a non-mutating read scoped to the current login, which is useful, but it says nothing about pagination behavior, output volume limits, or what happens if no account is logged in. Adequate but incomplete for a zero-annotation 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?

Two compact sentences: the first front-loads what is returned and the key constraint, the second supplies concrete answerable questions. No filler or redundancy; 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 read-only, zero-parameter-required tool with no output schema, the description communicates both scope (self profile + works) and the kinds of questions it answers, which effectively conveys the return shape. Missing only edge-case behavior (logged-out state, large result sets), so slightly under 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%, so the schema already documents limit (default 20, max 100), account (default SAU_ACCOUNT/main), and include_videos (default true). The description adds only the no-sec_user_id point and does not elaborate on any parameter, 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?

The description names a specific resource (the current account's profile and work list) and a specific actor (the logged-in account itself), and explicitly distinguishes it from the sibling douyin_user_profile by stating sec_user_id is not needed. An agent can immediately tell this is the 'self' read path versus the arbitrary-user 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?

It supplies concrete use cases ('how many posts have I made, recent plays/likes', 'which account is logged in'), which gives clear selection context, and the 'no sec_user_id' note implicitly routes non-self queries to douyin_user_profile. It stops short of an explicit when-not/exclusion statement, so a 4 is right.

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?

With no annotations, the description carries the full burden and does reasonably well: it declares the login/auth requirement, the internal two-step flow, and the degradation behavior when the short link can't be opened. It omits failure/rate-limit details and doesn't describe the direct-link format, so it is not exhaustive.

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?

A single dense paragraph, front-loaded with what the tool does before the mechanism and the fallback. Every sentence contributes, though the parenthetical example and internal-flow clause make it slightly packed.

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 parse tool with no output schema, the description covers the important agent-facing facts: input format, login requirement, output content (details + watermark-free link), and failure fallback. Enough to invoke correctly, with only minor gaps around error/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 coverage is 100%, so both parameters are already documented. The description illustrates the expected share_text shape with a concrete example, which is a small plus, but adds no meaning to the account parameter beyond the schema's own default-account explanation.

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: parses a Douyin share text/link into work details plus a watermark-free direct link. It also reveals the internal mechanism (follow short link → aweme_id → read details), which implicitly distinguishes it from douyin_video_detail, though it never names that sibling 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 clear context: use it when the user hands you raw share text or a v.douyin.com short link, and it notes the login prerequisite. The fallback (ask the user for the work id when the short link fails) effectively points at a manual alternative, but no sibling tool is named as the id-based route.

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?

With no annotations, the description carries the full burden and does disclose the critical behavior: a confirm-less call is a dry run that publishes nothing and returns a plan. However it omits auth/account prerequisites, failure behavior, and what happens to a scheduled post after acceptance.

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?

Purpose and the confirmation constraint are front-loaded, and every sentence carries an instruction. It is slightly verbose and repetitive with the bolded warning markers, which costs a point but not comprehension.

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 explains what the first call returns and how to proceed, which is the key gap to fill for a two-phase publisher. Missing pieces such as account/login prerequisites and error handling keep it short of 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 already 100%, so the baseline is 3. The description goes beyond the field-level text by explaining the call-to-call relationship between plan_id and confirm, which the schema states only in isolation.

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: 发布一条抖音图文（多图 + 标题 + 正文）. The 图文 qualifier cleanly separates it from the sibling douyin_publish_video, so an agent can pick the right publisher 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?

Explicitly states the workflow: first call without confirm publishes nothing and returns a plan; read the plan to the user, obtain explicit consent, then call again with the same plan_id plus confirm=true. It also states an exclusion — do not pass confirm=true directly or decide on the user's behalf.

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?

With no annotations, the description carries the full behavioral burden, and it discloses the single most important trait: without confirm the tool publishes nothing and only returns a plan. It also scopes what the returned plan contains (account, assets, title, body, tags, publish time). It does not cover auth requirements, failure modes, or what happens if plan_id is stale, so it falls 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?

The critical constraint (does not publish without confirm) is front-loaded in bold, and every sentence serves the confirmation protocol. Slightly long, and the closing '不要自己替用户决定发布' partially restates the earlier consent requirement, but overall tight for a high-risk write tool.

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 14-parameter write tool with no annotations and no output schema, the description supplies the necessary behavioral contract and explicitly enumerates the plan fields the agent will receive, compensating for the missing output schema. Remaining gaps (auth, error handling) are moderate.

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 meaning beyond the schema for the confirm/plan_id pair: it explains the idempotent two-step reuse of plan_id and that the plan must be echoed to the user first. Other parameters are left to the schema, which is acceptable at full coverage.

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 ('发布一条抖音视频') that an agent can immediately distinguish from the sibling douyin_publish_note (note vs. video). No ambiguity about what the tool does.

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 two-phase protocol: call without confirm to get a plan, read the plan back to the user verbatim, obtain explicit consent, then re-call with the same plan_id and confirm=true. It also states what NOT to do (don't decide for the user, don't skip confirmation). This is textbook when/when-not 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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses the login prerequisite, that links are watermark-free and time-limited (几小时), and that the tool only returns URLs without persisting files. This is meaningful operational context an agent needs to act correctly, though it says nothing about rate limits or failure modes.

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?

Single dense paragraph with the core search purpose front-loaded, followed by return fields and the expiry caveat. Every clause earns its place, though the return-field enumeration is slightly list-like and could be 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?

No output schema exists, so the description correctly enumerates the return fields (aweme_id, 文案, author, interaction data, watermark-free link) and adds the critical link-expiry caveat. Combined with the login requirement and follow-up routing, an agent has everything needed to call and use 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 description coverage is 100%, so all five parameters (sort, count, account, keyword, publish_time) are already documented with defaults and enum meanings. The description adds no parameter-level detail beyond the schema, making the baseline 3 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 (搜索/search) and resource (抖音视频/Douyin videos) scoped by keyword, and explicitly differentiates from downstream siblings like douyin_video_detail and douyin_user_profile by naming what each returned id feeds into. An agent can identify this as the discovery entry point without opening any other 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?

Gives clear context: it requires an active login, returns only addresses (不落盘), and routes follow-up work to douyin_video_detail and douyin_user_profile. It does not explicitly state when NOT to use it, but since no sibling competes as a search tool, the guidance is effectively 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the login requirement ('需要已登录'), which is the key operational trait, but omits whether the call is read-only, pagination/rate-limit behavior, or what happens on a stale/invalid sec_user_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?

A single dense sentence, front-loaded with the purpose followed by the return fields and the login caveat. Nothing is wasted, though the chained parentheticals make it slightly less scannable than a two-sentence layout.

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

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

With no output schema, the description compensates by enumerating the returned profile fields and noting the optional works list plus the login prerequisite. An agent has enough to call it correctly, though read-only status and error/failure behavior 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 the baseline is 3, but the description adds real value beyond the schema by specifying the sec_user_id format (MS4wLjABAAAA…) and its source in sibling tools, which helps the agent obtain a valid value.

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 ('看某个抖音用户的主页信息') and enumerates the exact fields returned (昵称、抖音号、简介、IP 属地、粉丝/关注/获赞/作品数). It also flags the optional works list. It does not explicitly contrast with the sibling douyin_my_profile, so it falls 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?

Gives concrete context: this needs a login to return the works list, and explains where to obtain sec_user_id (from the author field of douyin_search_videos / douyin_video_detail). It does not state when NOT to use it or name an alternative tool, so no explicit 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?

With no annotations, the description carries the full behavioral burden and does disclose the key trait that login is required before this call succeeds. It also implies a read-only retrieval and highlights a watermark-free direct link as a distinguishing output. It omits failure modes when unauthenticated, rate limits, and pagination/return shape details.

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 returned fields and followed by the prerequisite and ID source. No filler, no restatement of the tool name, and the bolded key output is easy to scan.

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 tool with no output schema, the field enumeration substitutes well for a documented return contract, and the login prerequisite is captured. Missing only error/edge behavior (unauthenticated failures, expired login) that an agent would need before invoking.

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 meaning beyond the schema by specifying the provenance of aweme_id (from search results, user profile, or a share link), which helps the agent source the required value correctly. The account parameter's default behavior is already documented in 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+resource (retrieve a single Douyin work's details) and enumerates the exact payload: caption, author, publish time, engagement data, cover, watermark-free play link, share page URL. This distinguishes it from siblings like douyin_search_videos and douyin_user_profile, which return lists rather than one work's detail.

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?

Tells the agent the precondition ('需要已登录') and where aweme_id comes from (douyin_search_videos / douyin_user_profile / share link), which is real routing guidance to sibling tools. It stops short of an explicit when-not-to-use or a note on choosing douyin_parse_share_link for URLs, so it is clear but not exhaustive.

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