Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Headline variants of a static ad

headline_variants

Test headlines on one static ad by generating several copies that keep the same image, product, and layout, using your own headlines or auto-written angles.

Instructions

Turn ONE finished static ad into several copies that differ ONLY in the headline, for an A/B test: same picture, product, layout, colours and every other line. Pass image, and either headlines (your own, up to 10) or count (default 5, max 10) to have distinct angles written for you in the saved brand's voice (never inventing numbers, prices, ratings or claims the ad or brand does not state); brief steers what to test. The ad's text is read first (3 credits), then one image edit per headline; each output is proofread and flagged (textCheck) if the rendered words do not match, never silently re-rendered. When the saved brand has a product photo and the ad shows that product, the photo rides with the edit and the product's label is read and checked against it: re-printed from the photo only when it came out wrong (the check alone is charged when it is right; one small extra charge finds the product first). fixLabel:false turns that off. The whole batch is priced before anything runs. Returns each headline, its angle and its image URL.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefNowhat to test, e.g. "price-led vs outcome-led" or "speak to busy parents"
countNohow many headlines to write when `headlines` is omitted (default 5)
imageYesthe finished static ad: URL, Library item URL, upload_file URL or local path
fixLabelNofalse = leave the product label exactly as rendered: no product lookup, no label check, no re-print (default on when the ad shows the brand’s saved product)
headlinesNoyour own headlines to test (up to 10); omit to have them written

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.366
    • addedInput schema / properties / fixLabel
      Added value: +{
+  "description": "false = leave the product label exactly as rendered: no product lookup, no label check, no re-print (default on when the ad shows the brand’s saved product)",
+  "type": "boolean"
+}
  2. Addedv0.1.272

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly=false, openWorld=true, idempotent=false, destructive=false): it discloses credit costs (3 credits to read text, one edit per headline), that the batch is priced before running, that outputs are proofread and flagged via textCheck, and that failed renders are never silently retried. Product-photo/label re-print behavior and the fixLabel off-switch are also spelled out.

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-loads the purpose in the first clause before diving into parameters and billing mechanics, and every clause carries information. It is dense and semicolon-heavy, with some parenthetical asides (the label-lookup charge) that a reader must parse slowly, so it is efficient but not maximally tight.

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 multi-step, credit-consuming generation tool with no output schema, the description covers cost, pricing-up-front, failure handling, brand/product constraints, and return values ('each headline, its angle and its image URL'). Nothing an agent needs to call it safely is missing.

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?

With 100% schema coverage the baseline is 3, and the description genuinely adds meaning: it reinforces count's default of 5/max 10, headlines' cap of 10, the semantic difference between supplying headlines vs letting them be written, and that generated copy 'never invents numbers, prices, ratings or claims.' brief's role ('steers what to test') is also clarified.

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 ('Turn ONE finished static ad into several copies that differ ONLY in the headline') and scopes it tightly to an A/B-test use case. The 'ONLY in the headline' constraint distinguishes it from siblings like hook_variants, multiply_ad and remix_static at a glance.

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?

Clearly explains invocation context: pass `image` plus either `headlines` (your own) or `count`, with `brief` steering the test. However it never names a sibling alternative (e.g. hook_variants) or states when NOT to use this tool, so the routing guidance is contextual rather than explicit.

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

Deploy Server

Other Tools