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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so safety is covered. The description adds only a list of data sections, with no note on aggregation cost, staleness, permission requirements, or what happens for companies without an installed website chat.

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 ~50-word run-on sentence built from nested 'plus… and… including…' clauses, restating the title verbatim. Nothing is front-loaded; the reader must parse the whole sentence to learn it is a read.

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 does tell the agent roughly what sections come back (policy, publishing history, autonomy settings, auto-run plan, installation readiness), which is the main thing needed. However it gives no notion of the response shape or how the sections relate, leaving it only minimally complete for such a broad aggregate read.

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% with two required parameters (company UUID and an environment enum), so the schema carries the semantics and baseline 3 applies. The description never mentions company or environment, adding nothing beyond the schema.

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?

It does name a specific verb ("Read") and enumerates the resources: execution policy, publishing history, chat/text/email autonomy, auto-run plan settings and installation readiness. But the enumeration is a run-on pasted from the title, and it draws no boundary against sibling reads such as summer_messenger_assistant_read, summer_autonomy_policy_preview or summer_support_policy_read, so an agent cannot tell which aggregate read it needs.

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?

There is no statement of when to call this versus the many other read tools in the messenger/autonomy cluster, and no exclusions or prerequisites (e.g. that it is the combined read while summer_messenger_autonomy_update is the write path). Usage must be inferred entirely from the resource list.

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