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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description goes well beyond that by disclosing the on-demand research kickoff and wait behavior, retryAfterSeconds semantics, the non-Shopify error, daily research allowance, the enriched:false fallback with dataNote, redirect naming, and the monthly store-lookup quota mechanics on capped plans.

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?

The description is dense but front-loads the core purpose (what profile data is returned) before moving to research/retry behavior, error cases, and quota rules. Every sentence carries needed information, though the single long paragraph is heavier than ideal and could be broken into clearer sub-clauses.

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 carries the full burden and does so thoroughly: it lists the returned profile fields, explains the research/retry flow, the non-Shopify error, the enriched:false fallback, and the quota model. An agent has enough information to call it and interpret both normal and edge-case responses.

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?

There is a single required parameter with 100% schema description coverage, and the schema already states that the domain is normalized automatically. The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 verb and resource: get the intelligence profile for a single Shopify store by domain. It enumerates the profile contents (revenue, orders, plan, tech stack, ads, traffic, etc.), which implicitly and clearly differentiates it from the narrower siblings get_store_ads, get_store_email, and get_store_emails, as well as from search_stores/find_similar_stores.

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 clearly explains the context of use (single store by domain), what happens when the store hasn't been researched (starts research and waits 15-30s), the retryWithAfterSeconds pattern, the error for non-Shopify domains, and quota consumption. It does not explicitly name alternative sibling tools, but the usage conditions are otherwise explicit.

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