Skip to main content
Glama

Set what it promotes and the goal

set_offer
Destructive

Sets what the project is and how Marsell sells for it: its type (one of twelve, by what people do when its marketing works; get_setup's types explains each and the week it gets), a second type, the switches (who buys it, where people get it, restricted goods, for children, inside a big company, ads on or off), the four facts (what it promotes, what people should do, whether it's out yet, whether people already look for it), whose accounts its posts come from (the business's own, a person's own, or both) and the owner's goal for the next weeks. Give any of them; the ones left out stay as they are.

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

Input Schema

NameRequiredDescriptionDefault
adsNoThe ads switch, the same one get_setup's ads question sets (set_preferences ads): ask the owner, never pick it for them. Free tools and campaigns start with ads off; left out, the type's default stands.
goalNoWhat the owner wants Marsell to reach, in their own words: ask them, never write it for them. With a number and a day ("$5k a month by 8 November", "500 stars by Christmas") it becomes the goal Marsell counts and plans every week toward when the setup finishes; it is also the campaign brief the planner reads. Send it empty to clear the one on file.
typeNoWhat the project is, by what people do when its marketing works (it sets what every week plans): shop (Shop: people buy products); paid_software (Paid software: people sign up and pay); free_tool (Free or open tool: people download and use it); local (Local place or service: people come in or book nearby); client_work (Client work: people hire you for a job); channel (Channel or show: people follow what you put out); release (Release: people wishlist, then buy a book, album, film or game); course (Course: people enrol); event (Event: people come on a date); community (Community: people join); fundraiser (Fundraiser or charity: people give money); campaign (Campaign: people sign, vote or act). A project is one thing; a person with several (a channel, an app, an open-source starter) makes one project each. Sets what it promotes and what people should do with it, unless you give those too. Leave it out when unsure: Marsell decides it from what is on file and asks the owner.
untilNoFor out_yet until: the end date, YYYY-MM-DD.
out_yetNoIs it out yet: not_launched (Not launched yet), launched (Launched), until (Running until a date).
sold_onNoWhere people get it: own_site (Its own site), marketplace (A marketplace), app_store (An app store), in_person (In person), platform_profile (A profile on a platform). Marsell reads it from the address when left out.
promotesNoWhat it promotes, the main one: products (Things people buy and own, physical or digital); software (Apps, platforms, tools, open source); services (Work done for people: professional, local, trades, agencies, freelance); places (Restaurants, cafés, hotels, gyms, studios, venues, attractions); events (Concerts, conferences, festivals, workshops, meetups); learning (Courses, coaching, schools, tutoring); media (Creators, podcasts, newsletters, publications); creative (Music, film, books, art, games); causes (Charities, nonprofits, fundraisers, petitions, campaigns); communities (Clubs, paid communities, teams, fan clubs); person (A personal brand, a portfolio, a job search); project (A side project, research, a one-off campaign).
who_buysNoWho buys it: people (People), businesses (Businesses), both (Both).
restrictedNoGoods the ad platforms limit or refuse that it sells: alcohol, gambling, cannabis, adult, weapons, crypto, supplements. An empty list says none.
person_nameNoWith posts_come_from person or both: that person's name as people know them.
second_typeNoA second type it also is, with type: an open-core company is paid_software with free_tool as its second type.
for_childrenNotrue when it is made mainly for children.
also_promotesNoAnything else it also promotes (never the main one again).
people_shouldNoWhat people should do, the main one: buy (Buy), sign_up (Sign up), book (Book or visit), attend (Attend), donate (Donate), join (Join or subscribe), follow (Follow), use (Use or contribute), vote (Sign or vote), hire (Hire), contact (Get in touch).
something_elseNoWhen none of the families fits: what it promotes, in a few words.
posts_come_fromNoWhose accounts its posts come from: business (its own accounts, speaking as itself), person (one person's own accounts: the maker of a free, open-source or side project who shares it from their own profiles, a coach, a freelancer, a practitioner posting as themselves; posts are then written by that person in first person, and nothing posts by itself unless they switch it on) or both (a founder-led business: its own accounts speak as the business, and the founder also posts about it from their own, in first person). Leave it out when unsure: Marsell decides it from what is on file and asks the owner.
people_could_alsoNoOther things people can do.
inside_big_companyNotrue for a team, programme or campaign inside a large company: Marsell then approaches no one and runs no ads for it on its own.
people_look_for_itNosearched: Yes, people search for this; new: No, it's new and needs showing first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the bar is lower. The description adds real value by clarifying merge semantics (omitted fields are preserved), but it does not explain the destructive/overwrite implications (e.g. clearing an existing goal) that matter for a 19-param write tool.

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?

It front-loads the purpose, which helps, but the body is one sprawling sentence with nested parentheticals that is hard to parse and repeats schema content rather than prioritizing. It earns some place but is bloated.

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

Completeness3/5

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

For a 19-param, all-optional, destructive tool with no output schema, the description covers all parameter families and merge behavior, but omits destructive consequences, sibling disambiguation, and any note on the outcome. Adequate but with clear gaps.

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 baseline is 3. The description groups parameters into coherent families (type, switches, four facts, posts source, goal) which aids orientation, but it adds little per-parameter meaning beyond what the schema already documents.

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 gives a clear specific object — it configures the project's offer/identity (type, switches, facts, posts source, goal) — and names a related tool (get_setup's types). However, sibling setters like set_type, set_goal and set_preferences clearly overlap, and the description never explains how this tool differs from them, leaving ambiguity.

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

Usage Guidelines3/5

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

It states partial-update semantics ('Give any of them; the ones left out stay as they are') which is useful when-to guidance, and schema notes say 'Leave it out when unsure'. But there is no explicit when-to-use-this vs the overlapping sibling setters, and no exclusions or prerequisites.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.