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

With no annotations at all, the description carries the full burden and adds only the metric list. It does not disclose the aggregation period (all-time? current month?), whether figures are scoped to the authenticated business, what permissions are needed, or whether results are cached. For an analytics tool, the missing time window is a material omission.

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?

A single tight sentence with no filler, front-loading the verb and resource. It is efficient, though the terseness comes at the cost of the behavioral and scoping details an agent needs.

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?

No annotations and no output schema mean the description must explain the return shape, and it only names three broad categories without saying what fields, what format, or over what time horizon. For a zero-parameter analytics endpoint whose entire value is its output, this leaves the agent guessing about the result and its scope.

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 there is nothing for the description to disambiguate; baseline 4 applies. The only gap is that no parameters existing means any filtering (date range, client) must be done elsewhere, which is not explained.

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?

Clear verb ('Get') and resource ('business analytics summary') with an enumeration of the metric categories covered (bookings, revenue, active clients). It reads distinctly against siblings like get_business_profile or get_upcoming_bookings, which are record-level rather than aggregate. It stops short of saying how this differs from a business profile snapshot.

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 word 'summary' implies this is the aggregate roll-up one should call instead of looping over booking or client tools, but that routing is never stated. No when-to-use, when-not-to-use, or named alternative is given. Usage is inferable only.

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