Marsell

Ad card

ad_card

On the owner's yes to an ad you offered, once they have seen the offer: keeps the picture (or the owner's own files), writes the ad's words in the business's voice and the buyers' language (a few tokens) and raises one card with where, who, the days and the most it can spend. Leave set_id out and it is for the picture or the owner's files you last offered in this chat, on the terms you offered, the countries too; name only what the owner changed. For the owner's files from an earlier offer, or files you didn't offer in this chat, name their attachments (with as) or film_id. Nothing spends until someone who may spend presses Start on that card. For a post to boost, the card comes once the post is live: until then it says so. Say what the card holds and that it waits for their Start. It needs an act key, and spends the owner's tokens as the chat's same tool would: say the price before you spend.

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": "ad_card"
  }
}

Input Schema

Name	Required	Description
`as`	No	with two or more attachments: one_ad (one ad with its tall 9:16 version for Stories and Reels) or carousel (2 to 10 pictures, in the order given); one attachment is one ad
`link`	No	where the ad sends people, when the owner named a page; omitted, the business's website
`brief`	No	the owner's own words for the ad (an offer, an angle), when they gave some
`place`	No	the place the owner named for the ad; omitted, where it was offered
`title`	No	with attachments: what they are, in a few words, when the owner said
`set_id`	No	the picture's set; left out, the picture this chat last offered as an ad
`caption`	No	with attachments: what they sell and to whom, in the owner's words, when they said; the ad's words are written from it
`ends_on`	No	the day it ends (YYYY-MM-DD), when the owner changed it; omitted, as offered
`film_id`	No	a film Marsell made, whose plan the owner approved, to run as a video ad; in place of set_id
`item_id`	No	the picture in the set; omitted, its first made picture
`per_day`	No	the amount a day, when the owner changed it, in their ad account's currency (20 for $20); omitted, as offered
`project`	No	The project's id or exact name. Optional when the account has one project.
`language`	No	the buyers' language, when it is not the language of this chat
`countries`	No	the countries for this ad (two-letter ISO codes), only when the owner named or changed them; omitted, as offered, which is Where ads may run unless countries were named then
`starts_on`	No	the day it starts (YYYY-MM-DD), when the owner changed it; omitted, as offered
`attachments`	No	the owner's own finished picture, video or pictures to run as they are, by their attachment ids (input.attached or attachment_read, sent here, on Telegram or Slack, or through an upload link), only when they ask to run the file itself; in place of set_id

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 8, 2026

addedInput schema / properties / as

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "one_ad",
+        "carousel"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "with two or more attachments: one_ad (one ad with its tall 9:16 version for Stories and Reels) or carousel (2 to 10 pictures, in the order given); one attachment is one ad"
+}

addedInput schema / properties / attachments

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "maxLength": 80,
+        "minLength": 1,
+        "type": "string"
+      },
+      "minItems": 1,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "the owner's own finished picture, video or pictures to run as they are, by their attachment ids (input.attached or attachment_read, sent here, on Telegram or Slack, or through an upload link), only when they ask to run the file itself; in place of set_id"
+}

addedInput schema / properties / caption

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 2000,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "with attachments: what they sell and to whom, in the owner's words, when they said; the ad's words are written from it"
+}

addedInput schema / properties / countries

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "maxLength": 40,
+        "minLength": 1,
+        "type": "string"
+      },
+      "minItems": 1,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "the countries for this ad (two-letter ISO codes), only when the owner named or changed them; omitted, as offered, which is Where ads may run unless countries were named then"
+}

addedInput schema / properties / film_id

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 80,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "a film Marsell made, whose plan the owner approved, to run as a video ad; in place of set_id"
+}

addedInput schema / properties / title

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 200,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "with attachments: what they are, in a few words, when the owner said"
+}

AddedNov 4, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, destructive=false, openWorld=false), the description discloses the materially important behaviour: the card only queues a spend, the spend is gated on an authorised Start press, an act key is required, the owner's tokens are consumed as the chat's same tool would, and the price should be quoted before spending. It also discloses the deferred-card case for boosted posts that are not yet live.

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

Conciseness3/5

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

The content is mostly load-bearing, but it is delivered as a long run-on stream with nested asides ('(a few tokens)', 'with as', 'the countries too') that make it slow to parse, and the instruction 'Say what the card holds and that it waits for their Start' is buried mid-paragraph rather than front-loaded. Tightening would preserve all the facts at half the length.

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

Completeness4/5

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

For a 16-parameter mutating tool with no output schema, the description covers the essentials an agent needs: preconditions (owner's yes, offer seen), defaulting behaviour for the many optional overrides, the act key requirement, and the spend gate. It stops short of saying what the created card returns or how the agent should report it back, though the guidance to summarise the card's contents partly compensates.

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 the baseline is 3, but the description adds real meaning on top: the default inheritance behaviour when set_id is omitted ('on the terms you offered, the countries too') and the operating rule 'name only what the owner changed', which tells the agent how to populate the many optional override fields. It also clarifies that attachments/film_id substitute for set_id rather than accompanying it.

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

Purpose4/5

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

The description states a concrete action — taking an owner's yes to an offered ad and 'raising one card with where, who, the days and the most it can spend', including writing the ad copy from the picture or the owner's files. That distinguishes it from ad_offer (making the offer) and ad_answer (answering), even without naming siblings. The phrasing 'raises one card' is idiosyncratic, but the resource and scope are unambiguous.

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?

Timing is explicit — only after the owner has said yes to an ad that was offered and seen it — and the description routes among variants: omit set_id for the last-offered picture, name attachments or film_id for earlier or unoffered files, and wait for the post to be live before boosting. It also states the when-not: nothing spends until someone authorised presses Start. Lacks only named alternatives to the sibling tools themselves.

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

All Marsell 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.