Skip to main content
Glama

Metadata MCP Connector

Create or Update Offer

create_update_offer
Destructive

Create or update Lead Gen or Landing Page offers in Metadata platform. Returns direct URL to access the offer in the platform. Lead Gen form fields take only the channel's predefined field types; the account's custom questions go in customFieldSelections, copied from get_offer, and on update omitting customFieldSelections keeps the current ones. A form takes at most 12 fields and custom questions together, and this tool cannot create a new custom field.

Input Schema

NameRequiredDescriptionDefault
dataYesOffer configuration data. Required fields depend on offer_type and channel - see description for details.
offer_typeYesType of offer to create

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / data / properties / customFieldSelections
      Added value: +{
      +  "description": "Lead Gen ONLY: the form's custom questions (the account's custom fields), each entry as get_offer returns it in content.customFieldSelections. Copy them when duplicating an offer. The list replaces the form's whole set: on update, omit it to keep the offer's current custom questions, and pass [] only to remove them all.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "id": {
      +        "description": "Id of the account custom field, from get_offer.",
      +        "type": "integer"
      +      },
      +      "language": {
      +        "description": "Locale of the text, as get_offer shows it (EN_US for most forms).",
      +        "type": "string"
      +      },
      +      "text": {
      +        "description": "The question as this form shows it, from get_offer.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "id",
      +      "text",
      +      "language"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / data / properties / fields / description
      Previous value: -"Field mappings. REQUIRED for all offer types and MUST contain at least one email-type entry — for Lead Gen use 'EMAIL' or 'WORK_EMAIL'; for Landing Page use 'EMAIL' (BUSINESS_EMAIL alone is NOT accepted — it can only be an EXTRA field alongside EMAIL). WARNING: Landing Page offers without an EMAIL mapping are rejected by the platform with `INVALID_LANDINGPAGE_FORM: Email mapping is required` — there is no valid lead-capture form without it. IMPORTANT: Lead Gen and Landing Page offer types accept DIFFERENT field values - see tool description for the full list per type. Do NOT use BUSINESS_EMAIL for Lead Gen (use WORK_EMAIL). Do NOT use COMPANY for Lead Gen (use COMPANY_NAME). Do NOT use COMPANY_NAME or WORK_PHONE_NUMBER for Landing Pages (use COMPANY and PHONE)."New value: +"Field mappings. REQUIRED for all offer types and MUST contain at least one email-type entry — for Lead Gen use 'EMAIL' or 'WORK_EMAIL'; for Landing Page use 'EMAIL' (BUSINESS_EMAIL alone is NOT accepted — it can only be an EXTRA field alongside EMAIL). WARNING: Landing Page offers without an EMAIL mapping are rejected by the platform with `INVALID_LANDINGPAGE_FORM: Email mapping is required` — there is no valid lead-capture form without it. IMPORTANT: Lead Gen and Landing Page offer types accept DIFFERENT field values - see tool description for the full list per type. Do NOT use BUSINESS_EMAIL for Lead Gen (use WORK_EMAIL). Do NOT use COMPANY for Lead Gen (use COMPANY_NAME). Do NOT use COMPANY_NAME or WORK_PHONE_NUMBER for Landing Pages (use COMPANY and PHONE). A Lead Gen copy of a form that has no EMAIL or WORK_EMAIL field adds none (see CUSTOM QUESTIONS)."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already disclose that the operation is not read-only, is destructive, and is open-world. Beyond that, the description adds valuable behavioral context: it returns a direct URL, explains custom question preservation on update, states a 12-field/question limit, and clarifies that new custom fields cannot be created.

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?

The description is compact and front-loaded, with purpose and return value early and operational constraints following. It is dense but appropriately sized for a complex mutation tool, with no obvious filler.

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 complex, destructive create/update tool with no output schema, the description covers purpose, return URL, field-type constraints, custom-field update behavior, and key limits. It does not discuss authentication, platform prerequisites, or broader workflow routing, but the schema and annotations fill much of that gap.

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% and the schema already documents parameters in detail. The description still adds cross-field meaning: Lead Gen fields must use predefined channel types, custom questions belong in customFieldSelections and should be copied from get_offer, omission preserves existing selections on update, and the combined field limit is 12.

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 uses a specific verb+resource ("Create or update ... offers") and explicitly covers the two offer types the tool manages, Lead Gen and Landing Page. It clearly distinguishes this from read-only siblings such as get_offer or find_offer_url.

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?

The description gives useful context: update behavior for custom fields is described, and it notes that the tool cannot create a new custom field. However, it does not explicitly name alternatives or fully state when to use this tool versus get_offer or find_offer_url, leaving some routing to inference.

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.

Resources