Công cụ MONA app create

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.

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.

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.

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.

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.

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.