Skip to main content
Glama
Sign In
monacloud-mcp

monacloud-mcp

Official
by mona-software
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Công cụ MONA app deploy

cloud_app_deploy

Deploy a git app or uploaded source to a live web app: upload a local directory as a ZIP or redeploy the existing source, then poll the build job until it runs.

Instructions

App từ git đã live: app host đầu tiên ~2–3 phút, deploy sau đó 10–20 giây. / Git apps are live. App upload: local_dir đóng ZIP mới → upload → chờ job → deploy; bỏ local_dir để redeploy bản đã upload. / Redeploy uploaded source or a git app and poll.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "app_id": "<app_id>"
    },
    "name": "cloud_app_deploy"
  }
}

Input Schema

NameRequiredDescriptionDefault
waitNo
app_idYes
sandboxNoThử 0đ, không tạo hạ tầng thật / Sandbox, no charge
local_dirNo
timeout_secNo
interval_secNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.0

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already state readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description usefully adds first-deploy timing (~2–3 minutes), subsequent deploy timing (10–20 seconds), the upload/wait/deploy flow, and polling behavior.

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?

The text is short, but it is split into slash-delimited bilingual fragments and duplicates content across Vietnamese and English. The clearest purpose statement appears at the end rather than being front-loaded, which weakens scanability.

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?

For a deploy tool with six parameters, no output schema, and annotations covering safety, the description covers source modes, timing, and polling adequately. It still omits key polling parameter semantics such as wait, timeout_sec, and interval_sec, and gives no guidance versus sibling deploy tools.

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 only 17%, so the description must explain parameters, but it only meaningfully clarifies local_dir. It does not explain wait, timeout_sec, interval_sec, app_id, or the full polling controls, leaving most parameters undocumented.

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?

The description names a specific action (deploy/redeploy) and source types (git app or uploaded source), and mentions polling. It is clear enough to distinguish from list/get/create siblings, but it does not explicitly differentiate cloud_app_deploy from the identical-looking vibecloud_app_deploy sibling.

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?

It gives an operational branch: provide local_dir to package/upload/deploy a new ZIP, or omit local_dir to redeploy the previously uploaded version. However, it gives no guidance on when to use this tool versus cloud_app_create, cloud_app_get, or vibecloud_app_deploy alternatives.

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