Add a subscriber to workflow.

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds non-duplicated context: the workflow must not currently have the subscriber active and abandoned-cart workflows reject this call. That explains why the operation is non-idempotent and where it fails, which is meaningful beyond the annotations. It still says nothing about success/return behavior or permission requirements.

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 content is two tight bullets with no filler, and the most consequential constraint (repeat-subscriber precondition) is listed first. The HTML markup (br, ul, li) is noisy overhead but the underlying text is lean. No wasted sentences.

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 7-parameter, nested-body, destructive mutation, the description supplies the failure constraints that the schema and annotations cannot express, and the 100%-covered schema plus explicit annotations carry the rest. No output schema exists, but for an add-to-workflow call the return surface is trivial. Adequate; only the absence of any permission/account-scoping note 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?

Schema description coverage is 100%, so every parameter (id/email alternatives, account, confirm, payload, payload_file, workflow_id) is already documented in the schema. The description names no parameters and adds no semantics beyond it. Baseline 3 applies.

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 tool name and title state a specific verb+resource (add a subscriber to a workflow), and the sibling set contains unambiguous counterparts (remove_subscriber_from_workflow, add_subscriber_to_segments) that make the resource separable. However, the description body itself never states the purpose and opens directly with 'Notes', so it contributes no purpose statement of its own. Clear in practice, but the description adds no sibling differentiation beyond the name.

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 two bullets give real usage conditions: the repeat-subscriber preconditions (must have completed the workflow, 'Allow repeat subscribers' must be on) and an explicit exclusion (abandoned cart workflows cannot use this endpoint). This tells the agent when the call will fail, which is above-average guidance. It stops short of naming alternatives for the excluded case, so it is not a 5.

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