ncloud_ncs_upload_part

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

With no annotations, the description carries the full burden and discloses important behavior: it returns an ETag, the body travels as text over MCP, and undersized non-final parts cause CompleteMultipartUpload to fail with EntityTooSmall. This gives an agent realistic expectations about the operation's constraints and failure modes.

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?

Three sentences with no filler: the first states the action and return value, the second gives the key limitation, and the third states the failure condition. Everything earns its place and the most important information is front-loaded.

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 mutation-style storage operation with no annotations and no output schema, the description adequately covers purpose, return value, size constraints, and failure behavior. It could add a bit more detail on the exact role of uploadId, but the schema already explains that it comes from create_multipart_upload.

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 coverage is 100%, so the baseline is 3, but the description adds meaningful semantic context for the body parameter ('Body is text over MCP') and reinforces the part-size constraint relevant to partNumber and body. This goes beyond the generic schema descriptions.

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 and resource: 'Upload one part of a multipart upload' and identifies the underlying HTTP endpoint (PUT /{key}?partNumber&uploadId). It distinguishes itself from the sibling upload_part_copy by focusing on uploading a part from a body rather than copying one.

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 clear guidance that the tool is suited for small parts and API verification, and explicitly says it is not for bulk binary transfer. It also warns that every part except the last must be at least 5 MB. It stops short of naming an alternative tool, but the when/when-not context is strong.

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