Same as s3_get_buckets: list buckets via s3/get_buckets_rmq. Prefer s3_get_buckets.
Same as s3_get_buckets: list buckets via s3/get_buckets_rmq. Prefer s3_get_buckets.
| Name | Required | Description | Default |
|---|---|---|---|
| s3uid | No | S3 account UID from s3_get_users.s3uid | |
| account_id | No | Numeric id from s3_get_users.id (alias; resolved to s3uid) |
Changes observed during successful MCP inspections.
v1.0.7Input schema / properties / account_id / descriptionPrevious value: -"Deprecated alias for s3uid; prefer s3uid"New value: +"Numeric id from s3_get_users.id (alias; resolved to s3uid)"Input schema / properties / s3uid / descriptionPrevious value: -"S3 account UID (s3uid) from s3_get_users or create_account/order. Numeric id (e.g. 13457) or string uid."New value: +"S3 account UID from s3_get_users.s3uid"Input schema / requiredRemoved value: -[
- "s3uid"
-]v1.0.4Input schema / properties / account_id / descriptionPrevious value: -"ID S3-аккаунта (если требуется; уточняйте через s3_get_users)"New value: +"Deprecated alias for s3uid; prefer s3uid"Input schema / properties / s3uidAdded value: +{
+ "description": "S3 account UID (s3uid) from s3_get_users or create_account/order. Numeric id (e.g. 13457) or string uid.",
+ "type": [
+ "string",
+ "number"
+ ]
+}Input schema / requiredAdded value: +[
+ "s3uid"
+]v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the fact that the call is routed through s3/get_buckets_rmq, but does not say whether that makes the operation asynchronous, slower, or a fallback path — the main behavioral question an agent would have about a "via queue" variant.
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?
Two short clauses: the equivalence statement first, then the routing preference. No filler, and the most decision-relevant information (prefer the other tool) is present and easy to extract.
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 no-required-parameter read tool with full schema coverage and an output-free contract, the definition covers equivalence and routing adequately. The remaining gap is behavioral: nothing tells the agent when the queued path is expected to be used or how it differs in outcome from s3_get_buckets.
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%: s3uid and account_id are both documented, including that account_id is an alias resolved to s3uid. The description adds nothing about parameters, which is acceptable given the schema does the work, but it earns no extra credit.
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 gives a specific verb and resource ("list buckets") and explicitly frames itself as an equivalent variant of the sibling s3_get_buckets, so an agent can tell the two apart. It does not explain what "via_queue" / s3/get_buckets_rmq actually means, so the underlying mechanism stays opaque.
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?
"Prefer s3_get_buckets" is an explicit routing instruction to the alternate sibling, which is the key selection signal here. It stops short of saying when this queued variant is the right choice (e.g., fallback when the direct call fails), so the condition for using it is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.