monacloud-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Công cụ MONA app create

cloud_app_create

Deploy a Git or local web app to MONA Cloud; use sandbox mode to estimate cost before deploying and returning the live URL.

Instructions

App từ git đã live: app host đầu tiên ~2–3 phút, deploy sau đó 10–20 giây. / Git apps are live. AI làm 99%: cloud_app_detect(local_dir) offline → cloud_app_host_list, cloud_prices/cloud_packages/cloud_plan_list và cloud_balance → cloud_app_create(local_dir, sandbox=true) nếu chưa có app host để ước tính chi phí giờ/gói → hỏi human một lần duyệt chi phí nếu chưa được duyệt → cloud_app_create(local_dir, sandbox=false) → poll tới done/succeeded → kiểm và trả URL. Cần DB/Supabase? cloud_base_create (beta) — chung account/ví MONA Cloud, khớp app deploy. Sau khi app có URL, CHỦ ĐỘNG hỏi tên miền riêng: human đã có domain → cloud_app_domain_add (CNAME); chưa có → cloud_domain_search gợi 3–5 đuôi (.vn trước nếu khách Việt) kèm giá VND, hỏi xác nhận chính tả + duyệt tiền → cloud_domain_buy (đã login) hoặc cloud_domain_reserve (chưa login: QR + claim_url) → cloud_domain_attach trỏ DNS + SSL. Human đăng ký MONA Pass bằng device flow một lần; hết credit 20k thì AI gọi cloud_topup và in QR (qr_ascii) ngay trong terminal, human chỉ quét bằng app ngân hàng; AI làm các bước còn lại. App git cloud_app_create(repo_url) đã live; không gọi agent_deploy cho deploy dự án. / Detect locally, estimate, obtain cost approval once, upload and deploy, create an optional Base, return URL, then attach an optional domain.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cloud_app_create"
  }
}

Input Schema

Name	Required	Description
`env`	No
`name`	No
`port`	No
`wait`	No
`branch`	No
`domain`	No
`sandbox`	No	Thử 0đ, không tạo hạ tầng thật / Sandbox, no charge
`repo_url`	No
`local_dir`	No
`build_type`	No
`dockerfile`	No
`app_host_id`	No
`timeout_sec`	No
`interval_sec`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.11.0Oct 3, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare a non-read-only, open-world, non-idempotent operation, and the description adds real behavioral context beyond them: first host takes ~2-3 min vs 10-20 sec for later deploys, sandbox costs 0, polling is required until done/succeeded, and a MONA Pass login plus credit top-up may be needed. Failure modes and rollback behavior are still absent.

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

Conciseness2/5

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

A single dense bilingual block that front-loads timing trivia and then strings together the entire multi-tool workflow, including steps for domain purchase and top-up that are not this tool's job. The trailing English summary is the only well-structured part; the rest is poorly segmented and hard to scan.

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?

With 14 parameters, 0 required, no output schema, and low schema coverage, the description should carry much more weight, yet it only covers the sandbox workflow and says the URL is returned. It is adequate to understand the overall flow but insufficient to invoke the tool's many configuration options correctly.

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 7% across 14 parameters; only sandbox is documented in the schema. The description explains the sandbox=true/false pattern and mentions local_dir and repo_url, but leaves name, port, env, wait, branch, domain, build_type, dockerfile, app_host_id, timeout_sec and interval_sec entirely unexplained in both places.

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 final English line states the verb chain plainly: detect locally, estimate, obtain cost approval, upload and deploy, return URL, attach an optional domain. That lets an agent distinguish it from siblings like cloud_app_deploy or cloud_base_create, even though the core purpose is buried under a wall of workflow narrative.

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

Usage Guidelines4/5

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

It gives explicit conditions: use sandbox=true first to estimate cost, then sandbox=false after one human cost approval, accept repo_url or local_dir, and it explicitly excludes agent_deploy for project deploys. The guidance is present but entangled with instructions for other tools (cloud_domain_buy, cloud_topup), which blurs which action belongs to this call.

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

Deploy Server