Skip to main content
Glama
atengk

@atengk/mcp-server-s3

by atengk

copy_object

Copies an object within the same bucket or across buckets by specifying source and target keys, enabling duplication, migration, or reorganization in S3-compatible storage.

Instructions

同桶或跨桶对象复制

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
source_keyYes
target_keyYes
source_bucketNo
target_bucketNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden and largely fails it: it never says whether an existing target_key is overwritten, whether object metadata/tags are preserved, what permissions or buckets are required, or whether large objects are streamed/copied server-side. Only the same-vs-cross-bucket capability is hinted at, which is really schema territory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short front-loaded phrase with zero padding, which is structurally clean. However the brevity is under-specification rather than efficiency: for a 4-parameter mutation tool, this size leaves essential information out.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write operation with no annotations, no output schema, and 4 parameters at 0% schema coverage, the description is not complete enough to call the tool confidently. Return shape is excusable given no output schema, but overwrite behavior, permissions, and parameter defaults are all missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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 and does not: it never explains that source_key/target_key are object keys, that source_bucket/target_bucket are optional and default to the current bucket, or what happens when only one bucket is supplied. The single phrase '同桶或跨桶' gestures at the optional bucket parameters but adds no usable semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('对象复制' / copy object) and adds a scope qualifier (same-bucket or cross-bucket), so an agent can tell what it does at a glance. It does not differentiate itself from the sibling move_object, which is the main tool an agent could confuse it with, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no mention of alternatives, even though move_object, upload_file, and download_file all overlap in intent. The agent must infer that copy is non-destructive and that move_object should be preferred when the source should be removed.

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