Select the winning variant and send it to the remaining audience. This triggers a real send to everyone who was held back — it cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | No | Metric the decision was based on (default opens) | |
| test_id | Yes | A/B test ID | |
| winner_variant | Yes | Label of the winning variant, e.g. B |
Changes observed during successful MCP inspections.
Input schema / properties / metric / descriptionPrevious value: -"Metric the decision was based on (default open_rate)"New value: +"Metric the decision was based on (default opens)"Input schema / properties / metric / enumPrevious value: -[
- "open_rate",
- "click_rate",
- "conversion_rate"
-]New value: +[
+ "opens",
+ "clicks",
+ "revenue",
+ "conversions"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true, and readOnlyHint=false, so the safety profile is largely covered. The description still adds real value by specifying the concrete effect — a real send to the held-back audience segment — and reiterating irreversibility in user-facing terms. It stops short of explaining whether the test is closed, what happens to non-winners, or send-volume/rate implications.
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 tight sentences with zero filler. The action is front-loaded and the risk warning follows immediately, which is the correct ordering for a destructive operation.
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 an irreversible, open-world send operation with no output schema, the description adequately covers the core consequence an agent must understand before invoking. Minor gaps remain around preconditions (test state, whether a winner must already be selected) and what happens to contacts not in the hold-back group.
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 the schema already documents test_id, winner_variant, and the metric enum with its 'default opens' behavior. The description adds no additional parameter meaning, making the baseline of 3 appropriate.
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 states a specific verb+resource pair ('Select the winning variant') and immediately extends it with the consequential second action ('send it to the remaining audience'). This is clearly distinguishable from siblings such as create_ab_test and list_ab_tests, which only create or enumerate tests rather than finalize them.
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: an agent can infer this is the step taken once a winner has been determined. However, there is no explicit guidance on prerequisites (must the test be running? must a winner be statistically determined?), no named alternatives (e.g., send_campaign for normal sends), and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.