Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Save ads to the swipefile

save_to_swipefile
Idempotent

Save ads to a named collection for later reuse, creating it if needed. Re-saving the same ad moves it into that collection instead of duplicating it.

Instructions

Save one or more ads/creatives to a named SWIPEFILE collection, creating the collection if it does not exist — the headless twin of the heart on every ad card in the web app. Use it whenever research turns up something worth keeping: a competitor ad from search_meta_ads / pull_competitor_ads, an organic post, or one of your own renders. Saved ads persist to the workspace board the web Swipefile tab shows, and feed the taste signal every future ad is planned against. De-dupes: re-saving the same ad (same key/link/media) MOVES it into the named collection instead of duplicating it. Free.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
brandNoprofile id/name from list_brands, this call only
itemsYesthe ads to save
collectionYesthe collection name — an existing one, or a new one to create

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.374
    • changedInput schema / properties / brand / description
      Previous value: -"brand id/name from list_brands, this call only"New value: +"profile id/name from list_brands, this call only"
  2. Changed1 schema field changedv0.1.371
    • addedInput schema / properties / brand
      Added value: +{
+  "description": "brand id/name from list_brands, this call only",
+  "type": "string"
+}
  3. Changed2 schema fields changedv0.1.243
    • addedInput schema / properties / items / items / properties / pageName
      Added value: +{
+  "description": "alias of advertiser",
+  "type": "string"
+}
    • addedInput schema / properties / items / items / properties / page_name
      Added value: +{
+  "description": "alias of advertiser: the field search_meta_ads returns, accepted as-is",
+  "type": "string"
+}
  4. Addedv0.1.161

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that the collection is auto-created if missing, that de-dup re-saving MOVES the ad rather than duplicating it, that saves persist to the workspace board the web tab shows, and that it feeds the taste signal. These are meaningful behavioral traits not derivable from readOnlyHint/idempotentHint alone.

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 core action and the de-dup caveat, and every functional sentence earns its place. Some marketing phrasing ('headless twin of the heart', 'feeds the taste signal') adds flavor at modest length cost, keeping it just below 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 3-parameter, non-destructive write tool with annotations and no output schema, the description covers creation, de-duplication, persistence, and cost. Nothing an agent needs to invoke it correctly is missing.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents brand, items, and collection thoroughly, including the key/link/media de-dup fields. The description only restates the collection-creation semantics, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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 (save) and resource (ads/creatives to a named swipefile collection) with clear scope, and the 'headless twin of the heart' framing distinguishes it from siblings like list_swipefile or export_swipefile_deck. An agent can identify it 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?

Explicitly says when to use it ('whenever research turns up something worth keeping') and names the source tools that feed it (search_meta_ads / pull_competitor_ads). It stops short of naming when NOT to use it or pointing to sibling alternatives like list_swipefile, so it is strong but not complete routing guidance.

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