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

Annotations declare destructive=true and non-idempotent, and the description adds real behavioral context beyond them: custom CSS is sanitized (no url(), @import, scripts), changes apply only to reports/dashboards made after the change, and an empty call returns current state. It stops short of warning that `clear` resets settings irreversibly, which would matter for a destructive tool.

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?

Front-loaded and information-dense, but it duplicates the entire 20-item font enum inline even though the schema already carries it, padding a single long sentence. The rest earns its place; the font list is redundant bulk.

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 usefully covers return behavior ('returns what is set'), scope of application, and CSS sanitization rules. Combined with the nested schema it is nearly complete, missing only explicit guidance on reversibility of `clear`.

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 coverage is 67%, and the description compensates by naming many fields (agency_name, logo, accent_color, contact_email, footer_note, logo_position, logo_size, header_style) and explaining `client` (leave out for agency default) and `clear` behavior. It adds meaning over the schema for the top-level params, though field-level semantics for less obvious keys rely on 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?

States a specific resource (the agency's report look: colors, fonts, cover, CSS) and the verb action (set in chat), scoping it to either the agency default or one client's own look. It is clearly distinguishable from siblings like report_templates or update_client_report, which are about templates and re-rendering rather than styling.

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?

Gives the key routing rule: omit `client` for the agency default, include it for one client's look, and use update_client_report to re-render an older report. It also explains the read pattern (no style and no clear returns current settings). It lacks an explicit when-not-to-use or a comparison against report_templates.

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