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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing beyond the read shape: no permission/auth requirements, no note that instance and URL data may be absent or stale while an app is provisioning, and no indication that the two private-key parameters are optional billing/ownership context.

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?

One tight sentence that front-loads the lookup-by-name constraint and then enumerates the returned fields; no padding or redundancy.

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 no annotations, no output schema, and a bare 'name' parameter, the description should explain optional-key behavior and any limits on returning instance/URL data for apps not yet running. It instead gives a single summary line, leaving an agent unequipped for edge cases.

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 coverage is 67%: 'name' is bare, while the two WIF private-key parameters carry strong inline warnings about dedicated keys and funding. The description adds nothing about the lookup key or when the optional keys are needed, so it leaves a real gap rather than compensating.

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?

States a specific verb ('looks up') and resource ('any app on the network by name') and enumerates the return payload (spec, expiry, instances, URLs). This distinguishes it from flux_get_app_logs and flux_get_app_stats, though it never explicitly names those siblings to route a confused agent.

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?

No when-to-use/when-not guidance and no alternative named, despite several close siblings (flux_get_app_logs, flux_get_app_stats, flux_get_identity). The title mentions URLs but the description gives no condition that would send an agent elsewhere.

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