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

Beyond readOnlyHint/destructiveHint=false, it discloses permission scoping ("counts only leads the caller may see"), data-availability conditions (Meta ad spend only when connected), a hard data gap (no site-visit tracking, therefore no visit conversion), and a strict output-use rule (quote 'text', never add a figure not in the result). These are exactly the behavioral traits annotations cannot express.

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?

Purpose and the trigger phrase are front-loaded, and every clause carries non-redundant information (metrics, conditionals, limitation, quoting rule). The single dense block mixes parameter definition with output guidance, which makes it slightly harder to scan than a segmented version would be.

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 takes on the burden of describing the return value and does so in detail — lead sources, purchase counts and amounts, form/quiz leads, median first-response time, most-requested items, conditional ad spend, and a ready-to-quote 'text' field. It does not cover error behavior, empty-period results, or how the 'text' field behaves for custom ranges, which leaves minor gaps for a permission-scoped reporting tool.

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 0%, so the description must carry the parameters entirely — and it does: it defines each enum value's window, marks week as the default, specifies the YYYY-MM-DD format for date_from/date_to, and implies custom is the case that consumes the two dates. No parameter meaning is left ambiguous.

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 concrete verb+resource framing ("How the caller's company is doing over a period") and enumerates the metrics returned, so the tool is clearly distinguishable from a narrow vertical summary. It stops short of naming the sibling summaries (leads_summary, retail_sales_summary, etc.) it should be preferred over, so routing between the many *_summary tools still requires inference.

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 a concrete trigger phrase («як справи за тиждень/місяць?») plus explicit period semantics (week = default last 7 days, month = last 30 days, custom = date_from/date_to), which tells the agent exactly when and how to call it. It also states conditional availability (Meta ad spend only when Meta is connected) and the constraint that site-visit conversion is unavailable. No explicit when-not-to-use or alternative-tool routing is provided.

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