delete_app

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no mention of cascade effects (e.g., whether related records are removed), permission requirements, or irreversibility confirmation, which is the kind of context a deletion tool should supply.

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?

Two short fragments with no waste, and the action is front-loaded. It is arguably too sparse rather than too long — the restated endpoint contributes little value relative to the missing context.

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?

Annotations cover the destructive/idempotent profile and the schema is trivial, but among dozens of delete_* siblings and multiple app-related mutations, the description gives no basis for correct selection. For a destructive operation, the definition is thinner than it should be.

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?

With a single self-evident parameter (app_id) and 0% schema description coverage, the endpoint path /apps/{app_id} does confirm the parameter is the app identifier. No format, type, or lookup guidance is added, but little is needed for one obvious ID field.

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 verb and resource ("delete App") and confirms the REST endpoint behind it, so the basic action is unambiguous. However, it largely restates the tool name and does not explain what an "App" is or how this differs from sibling operations on the same resource (update_app, set_app_active, get_app).

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?

There is no guidance on when to delete an app versus deactivating it via set_app_active or modifying it via update_app, and no preconditions or warnings. The agent must infer everything from the tool name.

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