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

Beyond the annotations (which already cover read-only, idempotent, non-destructive, closed-world), it discloses high-value traits: no secrets are returned in results, no remote calls are made, and no credits are consumed. It also explains the degraded state — readiness goes unknown after credential changes or evidence expiry — which is exactly the kind of behavior an agent cannot infer from structured fields.

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 sentences, front-loaded with what is read, then the cost/safety traits, then the limitation and the recommended follow-up call. The telegraphic 'No inputs, secrets in results, remote calls or credits' is compressed but unambiguous in context, and no sentence is filler.

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 an output schema present, return values need not be described, and zero params simplify the contract; the description still covers scope, cost, side-effect profile and next step. The one omission is a routing rule versus the similarly named webanto_get_connection_health sibling.

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 tool takes zero parameters, so the baseline is 4, and the description explicitly states 'no inputs', confirming that no filtering arguments are needed. Nothing further is required on this dimension.

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 opens with a specific verb+resource: it reads Shopify/WooCommerce account labels, credential configuration, expiry, sync observations and native connection-test evidence. That is concrete and scoped to commerce integrations rather than generic connectivity. It does not differentiate itself from the sibling webanto_get_connection_health, so an agent facing both still has to infer which to call.

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 clear operational context: run connection tests in the native integrations page (i.e., this tool does not run them), and follow with webanto_list_products to see synced products. The note that readiness becomes unknown after credential changes or evidence expiry tells the agent when the result is stale. The gap is that it never says when to prefer this over webanto_get_connection_health.

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