List your AnyHook 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 it excels: it discloses that inactive apps answer handshakes but discard event POSTs with 202 and reason app_inactive, that signing secrets are redacted to has_signing_secret plus a 4-char hint (plaintext only via rotation), and that legacyInboundUrls keep routing after a slug change. These are non-obvious behaviors an agent must know to interpret the returned list correctly.

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?

Three dense sentences with zero filler and the core purpose front-loaded in the first sentence. The second sentence explains the operational meaning of isActive, and the third clarifies secret redaction and legacy URL routing — both are decision-relevant. Every sentence earns its place.

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 output schema, the description must explain return-value semantics, and it covers the critical fields well: isActive behavior, secret redaction, and legacyInboundUrls handling. The only gap is operational detail such as pagination or result limits, which matters for a list tool but is absent. For a simple one-parameter call, what is present is otherwise sufficient.

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 100%: the only parameter, api_key, is already fully documented, including when it is needed over HTTP, when it is ignored over stdio, and its expected format. Per the rubric, the baseline is 3 when schema coverage is high and the description need not repeat it. The description adds nothing parameter-specific, but none is required.

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 first sentence names a specific verb and resource ('List apps in your AnyHook account') and enumerates the return contents (inbound URLs, sources, destination URLs). This distinguishes it from sibling mutation/event tools like anyhook_apps_create and anyhook_events at a glance — the agent knows exactly what this tool is for without opening any schema.

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?

The use case is clearly stated up front: this is the read-only account-overview tool that lists apps and their routing/status details. The context is unambiguous enough that an agent knows to reach for this when it needs an inventory of apps or app-level state. However, it does not explicitly disqualify alternatives or name when-not-to-use cases, which prevents a 5.

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