s3_presign_upload_part

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

The description reveals that URLs are short-lived bearer capabilities, that the response contains expiresIn/expiresAt, and that each URL should be treated as sensitive until expiry. It also clarifies that the upload happens directly to B2 by the client/worker rather than by this tool. This adds meaningful behavior beyond the annotations and does not contradict them.

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 dense but every sentence contributes: purpose, security/expiry behavior, the full multipart flow, and a size constraint. It is front-loaded with the core function before the workflow details. No filler or repetition.

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?

With no output schema, the description compensates by stating the key response fields (expiresIn/expiresAt) and the required flow with ETags. It covers prerequisites, sequencing, and the part-size rule. The exact response shape mapping part numbers to URLs is not spelled out, but enough context is present for correct invocation.

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 100%, so the schema already documents all five parameters. The description adds workflow-level context and the ≥5 MiB part-size rule, but does not add detailed parameter-level semantics beyond the schema. Baseline 3 is appropriate.

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 names a specific verb and resource: generating short-lived presigned PUT URLs for parts of an S3-compatible multipart upload. It distinguishes itself from siblings like s3_get_presigned_url by specifying PUT and multipart parts, and clarifies the tool does not perform the upload itself ('client/worker uploads each part DIRECTLY').

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?

It embeds the tool in a concrete workflow, naming the preceding and following calls and the ETag handoff. It also states a hard constraint ('Parts except the last must be ≥5 MiB'). It does not explicitly name alternative tools or when not to use them, so this is clear context without exclusions.

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