获取已登录账户的收藏夹目录。
获取已登录账户的收藏夹目录。
参数: username: HTML 客户端仅配置 Cookie 时必须提供用户名；通过 login 登录后可省略。 API 客户端忽略此参数，始终查询当前登录账户。
返回: folders: 收藏夹列表，每项包含字符串 id 和 name；无收藏夹时为空列表。 查询全部收藏时使用 folder_id="0"，该值不一定出现在目录中。
| Name | Required | Description | Default |
|---|---|---|---|
| username | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.7Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It explains authentication-dependent behavior, the return structure, empty-list behavior, and the special folder_id="0" caveat for querying all favorites. It does not cover error or unauthorized-access behavior, but for a simple read-only getter this is a minor omission.
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 front-loaded with the purpose and then organized into labeled 参数 and 返回 sections. Every sentence adds useful operational detail, with no filler or repeated schema information.
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-optional-parameter getter with an output schema, the description covers auth context, parameter semantics, return shape, empty-state behavior, and an edge case. An agent has enough information to invoke the tool correctly and interpret 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 0%, but the description fully documents the only parameter, username, including when to provide it, when to omit it, and how HTML vs API clients treat it. It also explains the special folder_id="0" semantics that are not visible in the input 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 first line states a specific verb and resource: retrieving the logged-in account's favorite folders. This clearly distinguishes it from sibling album tools like browse_favorite_albums and add_favorite_album even without naming them. The follow-up notes about username and returned fields reinforce the 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 gives concrete usage context: HTML clients with only a cookie must supply username, callers who logged in via login may omit it, and API clients should omit it and always query the current account. It does not explicitly name alternatives or say when not to use the tool, but the invocation conditions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.