Fetch your logged-in Douyin account's profile and published videos to check post count, recent plays and likes, and confirm the logged-in user.
看当前登录账号自己的主页信息与作品列表（不需要传 sec_user_id）。适合回答「我发了多少条、最近的播放/点赞如何」「这个号登录的是谁」。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 作品条数上限（默认 20，最多 100） | |
| account | No | 账号名（social-auto-upload 里登录时用的名字）。不传则用默认账号（SAU_ACCOUNT，兜底 main）。 | |
| include_videos | No | 是否返回自己的作品列表（默认 true） |
Changes observed during successful MCP inspections.
v0.2.0Does 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.