mfuns_categories

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns the complete category tree (返回完整分区树) and explains the semantic difference between leaf and parent categories (叶子分区可投稿，父级分区仅作导航). This goes beyond a basic query description, though it could mention potential authentication requirements or errors. Still, it is quite informative for a simple read-only 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?

The description is exceptionally concise: two short sentences. The first sentence states the purpose and usage context, the second clarifies the parameter situation and return semantics. Every word earns its place, with no filler or redundant 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?

Given the zero-parameter schema, the presence of an output schema, and the tool's simple nature, the description covers all necessary context. It explains what the tool returns, the structural distinction between leaf and parent nodes, and when to use it. The output schema handles detailed return fields, so the description need not elaborate further.

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 0 parameters, so the baseline is 4. The description explicitly states '无参数' (no parameters), confirming the absence of inputs. Schema coverage is 100% with an empty properties object, so there is no additional parameter information 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 queries the submission category tree (查询投稿分区树) and specifies its purpose: selecting category_id before publishing posts/videos. This specific verb+resource description distinguishes it from sibling tools like mfuns_create_post or mfuns_publish_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?

Explicitly indicates when to use the tool: '发布帖子/视频前用 mfuns_categories 选 category_id' (before publishing posts/videos, use mfuns_categories to select category_id). This provides clear context and implies it is the correct tool for category selection, differentiating it from other submission-related tools.

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