cloud_app_deploy

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

With no annotations, the description carries the full burden and discloses meaningful behavior: timing estimates (first host ~2–3 min, subsequent deploys 10–20 sec), the ZIP→upload→job→deploy pipeline, redeploy semantics for omitted local_dir, and the fact that the tool polls. Gaps remain — failure behavior and whether the live app is overwritten are unstated — but this is far more transparent than typical.

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 compact but structurally weak: it opens with a release-note-style 'Git apps are live' line and saves its clearest purpose statement for the end. Every point is duplicated in Vietnamese and English, roughly doubling the length without doubling the information.

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 mutating 6-parameter tool with no annotations and no output schema, significant gaps remain: there is no statement of what the tool returns (job ID? status?), what the required app_id refers to, or how this relates to app creation tools. The process and timing are well covered, but an agent still cannot predict the invocation result.

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 only 17%, so the description must compensate; it does well for local_dir, explaining its dual role of fresh ZIP upload versus redeploying the existing archive. But the required app_id is never explained as identifying the target app, and wait/timeout_sec/interval_sec are only gestured at through the single word 'poll'.

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 final sentence states a specific action — 'Redeploy uploaded source or a git app and poll' — with a clear verb and resource. However, the opening line 'App từ git đã live' reads like a changelog announcement rather than tool documentation, and the description never distinguishes this from the near-identical sibling vibecloud_app_deploy.

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 useful when-to-include/when-to-omit direction for local_dir ('bỏ local_dir để redeploy bản đã upload'), and the pipeline 'upload → chờ job → deploy' implies the conditions under which upload happens. But it names no alternative tools — cloud_app_create for new apps and vibecloud_app_deploy are never referenced — and provides no when-not-to-use guidance.

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