Platform-specific build or edit instructions

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses that output is enriched with house rules (naming, sender, UTMs, fallback syntax, footer, channel limits) and, when a snapshot exists, with account context including segments to reuse, live status, and shared content that would affect other live programs. It also states the safety-relevant boundary that no account mutation occurs.

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?

The opening sentence front-loads what the tool returns and for which platforms, then house rules, then the task catalogue. It is dense but nearly every clause carries information, and the long task list earns its space because the schema's enum has no per-value descriptions. The single-block prose is harder to scan than a short list 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?

For a read-only tool with no output schema, the description does a good job explaining what the steps contain and what context is layered in. It leaves open the shape of the returned instructions and whether house rules or a snapshot are prerequisites versus optional enrichments, which matters for a 7-parameter 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?

With 71% schema coverage, the schema leaves the twelve-value task enum and channels enum undescribed; the description compensates by glossing every task value, which is genuine added meaning. Platform is covered by both, but target, audience and attributes get only indirect treatment (attributes not addressed at all), so it stops short of full compensation.

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 deliverable (step-by-step instructions for a build or edit task) with a precise scope (Braze, Klaviyo or Iterable, in the platform's own terms, from a doc-verified procedure library). The enumerated task list makes the tool's surface concrete and clearly separates it from siblings like check_campaign or what_breaks.

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 twelve task names effectively encode when to reach for this tool (creating, editing live assets, changing audience, tracking, testing, pausing). It also states the operating mode clearly: 'The plugin never edits the account; a person follows the steps.' What's missing is explicit routing against siblings — nothing says to prefer check_campaign or what_breaks for validation versus this for procedure.

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