Validasi proyek Bedengan Apps

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

With no annotations provided, the description carries the full burden and does it well. It discloses that the tool does not submit, queue, or record anything, and it describes the response contents: detected app type, ignorable warnings, and hard errors that cause rejection. It also clarifies the consequences of errors on later submit/update calls.

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?

Although the description is long, every sentence earns its place: mandatory call order, side-effect transparency, response schema, error handling, and the retry loop. The critical instruction is front-loaded ('WAJIB dipanggil LEBIH DULU'), and examples are used efficiently to clarify warning versus error severity.

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?

Given there is no output schema, the description compensates by describing exactly what the response will contain and how to interpret it. It also explains the tool's non-mutating behavior, the consequences of hard errors, and the exact follow-up path. Nothing essential for correctly invoking and acting on this tool is missing.

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?

The schema already fully describes the only parameter, `path`, as an absolute local project folder path. The description adds context that this folder will be zipped and validated, but it does not introduce new parameter-specific constraints or format details. Baseline 3 is appropriate given 100% schema coverage.

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 description states a specific action: zip a local project folder and validate it through Bedengan App Hub without submitting anything. It also clearly distinguishes this from submit_app/update_app by saying it never queues or records anything, so the agent knows exactly what the tool is for.

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 explicitly mandates when to use the tool: always before submit_app or update_app, and even explains why ('tidak ada admin yang meninjau lagi'). It also gives the retry workflow: fix only mentioned issues, revalidate until 'ok': true, only then proceed. This is strong, actionable usage guidance.

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