upload_cover_image

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

The annotations already indicate a non-read-only, non-destructive, non-idempotent operation, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the uploaded material is 'permanent' (versus temporary media) and the operation returns a media_id. This clarifies lifecycle and outcome without contradicting any annotation.

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 entire description is a single concise sentence that front-loads the action and resource, then states the return value. There is no redundant wording or irrelevant detail; every word 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 simple one-parameter upload tool with an output schema present, the description covers the essential purpose and result. It is missing contextual details like image format/size constraints and does not explicitly differentiate from upload_content_image, which could be ambiguous. Overall, it is sufficient for correct invocation in most cases, but not exhaustive.

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%, so the description must compensate. It clarifies that file_path refers to a local image on the machine ('本机图片'), which adds meaning beyond the bare 'File Path' title. However, it does not specify path format, supported image formats, size limits, or whether relative/absolute paths are accepted, leaving some semantic gaps.

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 states a specific verb ('上传' - upload), a resource ('本机图片' - local image), and the purpose ('永久封面素材' - permanent cover material), and ends with the expected return value (media_id). It distinguishes this tool from siblings like upload_temp_media (temporary) and upload_video_material/upload_voice_material (different material types) through the 'permanent cover' qualifier.

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 implies the use case: when you need to upload a local image as a permanent cover material. However, it does not explicitly state when to choose this over alternatives such as upload_content_image or upload_temp_media, nor does it mention any exclusions or conditions. The guidance is inferred from the tool name and wording rather than directly stated.

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