Aetherya

Compare image creatives

aetherya_compare_creatives

Compare 2+ image creatives (thumbnails, display banners, social images) against a synthetic audience. Creates the experiment, uploads the images, attaches the audience and drafts the comparison (free). It then returns status 'needs_price_confirmation' with the quoted simulation sessions; nothing is spent until you re-call with accept_sessions >= the quote (pass accept_sessions up front to skip the pause). To confirm a draft already created, pass comparison_id + accept_sessions only. Cost scales with creatives x personas; an audience group is capped at 10 personas per segment. choice_task adds a forced-choice round (choiceCost in the quote). Collect the ranking with aetherya_get_result kind 'creative_comparison'. Results are simulated, not real-user data.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aetherya_compare_creatives"
  }
}

Input Schema

Name	Required	Description
`name`	No	Name for the comparison.
`exposure`	No	glance = a split-second scroll-past view.
`platform`	No	Where the creatives run.
`creatives`	No	2-10 creatives to compare. Needed unless you pass comparison_id.
`choice_task`	No	Also run a forced-choice task (each persona picks one creative). Adds sessions; the quote shows choiceCost.
`persona_ids`	No	Persona ids (see aetherya_list_audiences), instead of an audience group.
`comparison_id`	No	Confirm and run a draft created by an earlier call.
`accept_sessions`	No	Sessions you accept to spend; must cover the quote.
`audience_group_id`	No	Audience group (see aetherya_list_audiences).

Output Schema

Name	Required	Description	Default
`next`	No
`source`	Yes
`status`	Yes
`choiceCost`	No
`comparisonId`	No
`experimentId`	No
`estimatedSessions`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Discloses behavior well beyond the annotations: it creates an experiment, uploads images, attaches an audience, pauses at status 'needs_price_confirmation', spends nothing until accept_sessions covers the quote, and costs scale with creatives x personas. Also surfaces the 10-persona-per-segment cap, the added choiceCost for choice_task, and that results are simulated rather than real-user data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose and the free/paid split, and nearly every sentence carries actionable information (cost, caps, confirmation path). It is a dense single block rather than scannable segments, which slightly hurts readability but not content value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, multi-step, money-spending tool, the description covers the lifecycle end to end: creation, quoting, confirmation, and where to retrieve results. With an output schema present it correctly omits return-value detail, leaving no critical gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: accept_sessions must cover the quote, comparison_id confirms a prior draft, persona_ids substitute for audience_group_id, and choice_task inflates the quote with choiceCost. Not a full 5 since exposure/platform semantics remain schema-only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Compare 2+ image creatives ... against a synthetic audience') and scopes the asset types explicitly (thumbnails, display banners, social images), which separates it from copy/flow testers among the siblings. An agent can identify this as the image-creative comparison tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives two concrete call paths (create fresh with accept_sessions up front vs. confirm an existing draft with comparison_id + accept_sessions), names the follow-up tool aetherya_get_result kind 'creative_comparison', and points to aetherya_list_audiences for audiences. It lacks an explicit 'when not to use this' (e.g. vs. aetherya_test_copy), so it falls just short of 5.

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

All Aetherya tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?