Skip to main content
Glama
damurka

jumia-vendor-center

by damurka

create_products

Create new products in Jumia Vendor Center as an asynchronous feed. Poll the returned feed ID to track completion and obtain product IDs and QC status for subsequent updates.

Instructions

Create new products (async feed). Poll the returned feedId with get_feed_status() until status is COMPLETED, then call it again (or list_products by sellerSku) to learn each product's real productSid and QC status - both are required before you can update stock, price or status on a newly-created product.

Each item in products (per the published schema): name: {"value": "...", "translations": [{"language": "en", "value": "..."}]} description: {"value": "...", "translations": [...]} sellerSku: str (required, your own unique SKU) parentSku: str (REQUIRED, despite the published schema marking it optional - confirmed live: omitting it on a standalone, non-variant product fails with "Required field [Product.ParentSKU] is missing or null." For a single listing with no size/color variants, just set this equal to sellerSku. Only set it to something else when you actually want to group size/color variants together - every product sharing a parentSku must then pass the SAME images.) variation: str (required if parentSku groups variants; for a standalone product, set it equal to sellerSku/name too) brand: {"code": ..., "name": "..."} category: {"code": ..., "name": "..."} (from list_categories) images: [{"url": "https://...", "primary": true}, ...] (>= 1 primary required) price: {"currency": "NGN", "value": 12000, "salePrice": {"value": 9000, "startAt": "2026-09-10", "endAt": "2026-09-20"}} stock: 50 attributes: [{"name": "color", "value": "Black"}, ...] (from get_attribute_set - call it first to see which attributes this category marks mandatory, e.g. product_weight/short_description are required for AC Chargers) businessClients: [{"businessClientCode": "jumia-ng", "price": {...}}, ...] (needed for a global/multi-country seller selling in local currency)

Before calling this for a real-world branded product, SEARCH for the manufacturer's actual spec sheet, description copy, and product image URLs (their regional store site) rather than inventing name/description/spec/image content - Jumia's own content guidelines expect accurate listings, and a fabricated spec (wrong wattage, invented weight, wrong included accessories) risks a QC rejection or a listing that doesn't match what ships. If the manufacturer's site blocks a plain fetch (403), a real browser session (e.g. claude-in-chrome) often gets through where a headless fetch doesn't. Only fields you truly cannot find published anywhere (e.g. shipping weight) should be flagged to the user as an unverified estimate rather than silently guessed.

Cap ~1000 products per call - this tool does not auto-chunk larger lists for you (chunk them yourself and call this repeatedly, tracking each feedId, so a failure in batch 6 doesn't force you to redo 1-5).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
shop_idYes
productsYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description fully discloses the async result flow, the requirement to poll, the quirk that parentSku is required despite the schema marking it optional, shared-image constraints for variants, and the ~1000-item cap with no auto-chunking. This goes well beyond the tool name and schema to prevent incorrect invocation.

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 long but information-dense; each section earns its place. It is front-loaded with the async workflow, then parameter semantics, then sourcing policy and chunking guidance, with no filler or 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?

For a complex creation tool with an empty schema, no output schema, and no annotations, the description covers invocation flow, required follow-up, dangerous assumptions, data sourcing, error-avoidance, and chunking. An agent has enough context to call this correctly and understand the lifecycle.

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 description coverage is 0%, and the description compensates thoroughly: it documents the structure of each products item, gives concrete JSON examples for name, description, price, images, stock, attributes, and businessClients, and flags parentSku as required. The only parameter not expanded is shop_id, which is self-explanatory in this context.

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?

States a specific action 'Create new products' and immediately identifies it as an async feed, which distinguishes it from synchronous siblings like update_products and sync_products. The scope is clear: creation, not modification or synchronization.

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?

Provides explicit workflow conditions: poll get_feed_status until COMPLETED, then learn productSid and QC status before updating stock/price/status; call get_attribute_set and list_categories first; chunk lists because there is no auto-chunking. It does not explicitly contrast with sibling tools such as update_products, but the create-vs-update boundary is strongly implied.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/damurka/jumia-vendor-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server