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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond them: it is free of quota cost, requires the Pro plan or higher, and wraps a specific endpoint (GET /api/v2/hook-studio/cta-settings), all of which affect whether and how the agent calls it.

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?

Two dense sentences, front-loaded with the read-only marker and the resource, with parenthetical field lists that earn their space. The trailing '(Wraps GET /api/v2/...)' is mildly redundant with the tool name and annotations but still useful for debugging.

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 compensates by naming the returned goals shapes (source tagged, implicit, none; primary goal) and the CTA settings fields. Combined with the plan requirement and endpoint disclosure, an agent has enough to call it correctly; only the absence of any error/quota behavior detail keeps it from a 5.

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 optional parameter with 100% schema description coverage, including the nuance that a brand-bound key may omit brandId. The description adds no brandId-specific meaning, so the baseline of 3 applies since the schema carries the parameter burden.

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 names a specific verb+resource pair ('goals and CTA check settings') and enumerates the concrete fields returned (ctaLevel, ctaPaidLevel, organicSupportingHosts, autoApplyPrimaryCta), so the agent knows exactly what comes back. It does not explicitly distinguish itself from the sibling cta_settings_update or cta_check, leaving that inference to the reader, which keeps it just below a 5.

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?

Usage is implied by '[read-only]' plus the sibling cta_settings_update, but the description never states 'use this to read, use update_ instead to modify' or how it differs from cta_check. It does add a real prerequisite ('Needs the Pro plan or higher'), which is actionable gating information, so it is better than no guidance but short of explicit when/when-not routing.

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