Skip to main content
Glama
hostkey-cloud-ru

hostkey-mcp-server-ru

Official
by hostkey-cloud-ru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

s3_delete_payment_account

Destructive

Initiate S3 account deletion via service cancellation in billing (s3/delete_payment_account). DESTRUCTIVE: an end date will be set on the active service. Requires HOSTKEY_ALLOW_DESTRUCTIVE=1.

Instructions

Initiate S3 account deletion via service cancellation in billing (s3/delete_payment_account). DESTRUCTIVE: an end date will be set on the active service. Requires HOSTKEY_ALLOW_DESTRUCTIVE=1.

Input Schema

NameRequiredDescriptionDefault
s3uidNoS3 account UID; omit only if the token is bound to a single S3 account
confirmYesMust be true to run the operation.
account_idNoDeprecated alias for s3uid / get_users.id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.7
    • changedInput schema / properties / account_id / description
      Previous value: -"Deprecated alias for s3uid"New value: +"Deprecated alias for s3uid / get_users.id"
  2. Changed2 schema fields changedv1.0.4
    • changedInput schema / properties / account_id / description
      Previous value: -"ID S3-аккаунта (если требуется; уточняйте через s3_get_users)"New value: +"Deprecated alias for s3uid"
    • addedInput schema / properties / s3uid
      Added value: +{
+  "description": "S3 account UID; omit only if the token is bound to a single S3 account",
+  "type": [
+    "string",
+    "number"
+  ]
+}
  3. Changed1 schema field changedv1.0.3
    • changedInput schema / properties / confirm / description
      Previous value: -"Нужно true, чтобы выполнить операцию."New value: +"Must be true to run the operation."
  4. First observedv1.0.0

TDQS

A3.6/5.0
Behavior4/5

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

The annotations already declare destructiveHint=true, so marking it DESTRUCTIVE repeats structured data. What earns credit is the added semantics: deletion is implemented as a scheduled service end date rather than an immediate purge, plus the required environment flag — neither of which is visible in the annotations.

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

Conciseness4/5

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

Two tight sentences with the destructive warning front-loaded immediately after the purpose. The parenthetical API path is slightly redundant but minimal overhead; nothing is padded.

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

Completeness3/5

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

Covers the destructive nature, the mechanism (end date on the service), and the env-var gate, which is solid for a no-output-schema mutation tool. It omits two things an agent needs: how this differs from s3_delete_account, and that the action appears reversible via the s3_cancel_account_deletion sibling.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so s3uid optionality, the confirm requirement, and the deprecated account_id alias are already fully documented in the schema. The description adds no parameter-level information beyond the schema, which meets the baseline but no more.

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 and resource ('Initiate S3 account deletion via service cancellation in billing') and names the underlying API path. However, it does not differentiate itself from the closely-named sibling s3_delete_account, which is the single most important distinction an agent must make here.

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

Usage Guidelines3/5

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

Provides a real precondition ('Requires HOSTKEY_ALLOW_DESTRUCTIVE=1'), which is actionable usage guidance. But it never says when to prefer this tool over s3_delete_account or s3_cancel_account_deletion, so the agent is left to guess between near-identical siblings.

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

Deploy Server

Other Tools