Skip to main content
Glama

create_marketplace

Create a new marketplace integration for a project from one of the channels in list_marketplace_channels. Use this when the user asks to add a marketplace. channel_code is the channelCode from list_marketplace_channels. Returns {integrationId, action:'create', status, kind:'marketplace', editUrl, nextStepType, message}. status is 'created' (the marketplace exists; continue with configure_marketplace_step starting at nextStepType) or 'prerequisite_not_met' (HTTP 409 — message explains what must be done first, e.g. an offer/primary feed must exist first, another marketplace is not included in this Koongo account (the message explains it), or the primary channel must be created first — see nextStepType). primary_sync marks this as the primary product source; order_sync enables order synchronization if the channel supports it; multichannel_code links a multichannel definition when the channel offers one (see get_marketplace_channel). definition_code picks a SPECIFIC definition of the channel when it has more than one (e.g. Amazon/Kaufland expose 'Offers' AND 'New Products') — take it from get_marketplace_channel definitions[].definitionCode; OMIT it to create the channel's default/primary definition. (versionType primary/secondary in get_marketplace_channel tells the definitions apart; it is NOT the same as primary_sync, which just marks this integration as the primary product source.) name is an OPTIONAL human-readable label so you can later find this marketplace by name (names are not unique — set_marketplace_name can change it later). project_id is OPTIONAL (inferred for a single-project customer; if project_id_required is returned, call list_projects).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "channel_code": "<channel_code>"
    },
    "name": "create_marketplace"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoOptional human-readable name for the new marketplace.
order_syncNoEnable order synchronization (only if the channel supports it).
project_idNo
channel_codeYeschannelCode of the marketplace channel (from list_marketplace_channels).
primary_syncNoMark this marketplace as the primary product source.
definition_codeNoPick a specific definition (definitionCode from get_marketplace_channel) when the channel has more than one, e.g. New Products vs Offers; omit for the default/primary definition.
multichannel_codeNoDefinition code of a multichannel option when the channel offers one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (which only declare non-readonly, non-destructive, non-idempotent), the description discloses the exact response shape, the two possible status values, and the meaning of the HTTP 409 prerequisite_not_met case with concrete causes (missing offer/primary feed, marketplace not in the Koongo account, primary channel missing). That is precisely the operational context annotations cannot convey.

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 required information is front-loaded and every clause carries signal, but the body is a single dense paragraph with stacked parentheticals (the 409 explanation and the versionType aside) that is harder to scan than a short bulleted structure would be. It earns its length, just not its formatting.

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?

With no output schema, the description supplies the return contract inline (integrationId, status, kind, editUrl, nextStepType, message) plus the failure branch, and it explains the optional-parameter fallbacks. For a 7-parameter creation tool in a large sibling set, 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.

Parameters5/5

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

Schema coverage is already 86%, yet the description still adds real meaning: definition_code is sourced from get_marketplace_channel definitions[].definitionCode and must be omitted for the default, and the text explicitly disambiguates versionType primary/secondary from primary_sync. It also explains that name is non-unique and mutable via set_marketplace_name, and why project_id can be omitted.

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 first sentence states a specific verb and resource ('Create a new marketplace integration for a project') and immediately scopes the input source to channels from list_marketplace_channels. This clearly separates it from siblings like clone_marketplace, create_ad, and configure_marketplace_step without the agent needing to open any 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 gives an explicit trigger ('Use this when the user asks to add a marketplace'), names the prerequisite lookup tool (list_marketplace_channels, get_marketplace_channel), and routes the agent forward to configure_marketplace_step starting at nextStepType. It also covers the project_id_required fallback to list_projects, so the whole call sequence is spelled out.

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