Skip to main content
Glama
hans100x-dotcom

Vereel MCP Server

Change an offer in review

vereel_update_offer
DestructiveIdempotent

Modify a brand offer while it is still in review by updating only the fields you provide; public or rejected offers cannot be changed through the API.

Instructions

Change an offer the brand created through the API, while it is still in review. Only the fields you give change. To reorder or remove photos, pass photos with the offer's current photo URLs in the new order (leaving one out removes it); to add a photo use vereel_add_offer_image. An offer that is already public or rejected cannot be changed through the API. Needs a read-and-write brand token.

Input Schema

NameRequiredDescriptionDefault
nameNoCampaign name shown to creators
photosNoThe offer's current photo URLs in the new order; leaving one out removes it. The first is the cover.
offerIdYesThe offer's id, as returned by vereel_create_offer or vereel_list_my_offers
remarksNoAnything else creators should know
audienceNoWho the creator's audience should be
currencyNoPLN or EUR; defaults to the brand's currency
isBarterNoThe creator receives a product or service instead of (or besides) money
languageNoLanguage of the campaign; defaults to the brand's language
isPaymentNoThe creator is paid
offerTypeNoPRODUCT, SERVICE or EVENT
platformsNoWhere the creator publishes: instagram, tiktok, youtube, x
eventPlaceNoEVENT only: where it takes place
applyByDaysNoCreators can apply for this many days after the offer goes live; default 21
categoryIdsNoUp to 3 category ids from vereel_list_categories
descriptionNoWhat the campaign is about and what the creator does
trackingUrlNoA page to lead to, or null to switch tracking links off
deliverablesNoHow many pieces of each kind the creator publishes
eventDateTimeNoEVENT only: when it starts, ISO 8601
followerMinimumNoSmallest follower count a creator needs; one of 1000, 2000, 5000, 10000, 25000, 50000, 100000
presenceAddressNo
presenceEndDateNo
productIncludedNoA paid offer also includes a product or service. Always true for barter.
ticketsIncludedNoEVENT only: the creator receives tickets or entry
expectedAudienceNoFree-text description of the audience wanted
additionalPaymentNoCash paid to the creator
logisticsRequiredNoSomething must be sent or arranged before the creator can start; default true
presenceStartDateNo
includedDescriptionNoWhat the creator receives. Required when a product, service or tickets are included.
productServiceValueNoValue of the product or service the creator receives
publicationDurationNoHow long the post stays online; default DAYS_30
textProvidedByBrandNoThe brand supplies the post text
requiresGoodsShippingNoThe brand ships goods to the creator
hashtagsProvidedByBrandNoThe brand supplies the hashtags
requiresPhysicalPresenceNoThe creator must be somewhere in person

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare mutation, destructive, idempotent, and open-world behavior. The description adds important operational context: partial updates only change supplied fields, photo omission removes photos, public/rejected offers are immutable via API, and a read-and-write brand token is required.

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

Conciseness5/5

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

The description is front-loaded with purpose and constraints, then covers photo handling and auth. Every sentence contributes actionable information without repetition.

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?

Given 34 parameters but 91% schema description coverage, annotations covering safety traits, and no output schema, the description provides the missing operational essentials: state eligibility, partial-update behavior, photo handling, alternative tool routing, and auth requirements.

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 description coverage is high at 91%, so the schema carries most parameter detail. The description still adds meaningful semantics beyond the schema, especially that omitted fields are unchanged and how the photos array should be passed for reorder/removal versus addition.

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?

The description states a specific verb and resource (change an offer), scopes it to offers the brand created through the API while in review, and distinguishes it from sibling actions like vereel_create_offer and vereel_add_offer_image. An agent can identify what this tool does without reading 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 Guidelines5/5

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

It explicitly covers when the tool can be used (offer still in review) and when it cannot (already public or rejected). It also names the correct alternative for adding photos, vereel_add_offer_image, making the routing decision clear.

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