eda_lib_classification_create_primary

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

With no annotations, the description must carry the full burden of behavioral disclosure. It does mention the deprecation and the return type ('returns: 分类索引'), but it does not describe side effects (e.g., that this is a write operation that modifies the library), potential error conditions, or prerequisites like needing a valid library UUID. For a create operation, this is a significant gap.

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 mixes English signature and Chinese text, with redundant information (the signature is repeated conceptually in the Chinese description). It is not tightly structured or front-loaded; the deprecation warning appears after the signature and Chinese text. It is not overly long, but it could be more organized and concise.

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 there is no output schema and no annotations, the description is incomplete for a create operation. It does not mention prerequisites (e.g., the library must exist, permissions needed), possible failures, or the structure of the returned index. While it does state deprecation, it lacks guidance on alternatives or any context about when this tool would ever be invoked. For a deprecated tool, one might argue less is needed, but the description still fails to provide enough for an agent to safely invoke it if they somehow need to.

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 includes the function signature with parameter names and types (libraryUuid: string, libraryType: ELIB_LibraryType, primaryClassificationName: string), which adds meaning beyond the generic 'args' array in the schema. However, it does not explain the semantics of each parameter (e.g., what values libraryType accepts, what constitutes a valid name). The schema only describes 'args' as an ordered JSON array, so the description compensates partially but not fully.

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 action: '创建一级分类' (create primary classification) and includes the function signature with the verb 'createPrimary'. It distinguishes from sibling 'create_secondary' by explicitly indicating 'primary' in both name and description. The resource (classification) and scope are 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?

The description warns 'deprecated: since EDA v3.2; dropped EDA v3.3', which is a negative usage guideline (don't use it), but it does not provide any alternative tool or context for what to use instead. There is no positive guidance on when to use it (since it's deprecated, never) and no mention of sibling tools that could replace it. This is insufficient for an agent deciding between this and other classification tools.

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