The data

EDITED has spent 12+ years building one of the most comprehensive structured datasets in retail — 90,000 brands and 5bn+ SKUs across three verticals: apparel (including footwear and accessories), beauty, and home. The MCP gateway exposes EDITED's data across three domains, each a separate backend namespace. Alongside the query tools, a set of identifier-resolution and data-quality helpers in the mdmcp namespace supports market-data queries; the Trend & Research and Messaging & Promotions domains resolve their own identifiers with their own tools.

This page describes what each domain contains and what you can do with it. For the complete tool catalogue with parameters and schemas, see the Reference. For a worked end-to-end example, see Recipes → Example workflow.

---

Competitive Market Data

Namespace prefix: mdmcp

Live structured data on fashion retail products across thousands of retailers and brands worldwide. Updated continuously. Covers pricing, stock levels, discounts, new arrivals, colours, patterns, and sizing — at both the individual product level and in aggregate. Available via MCP for the last two years, kept on fast infrastructure for real-time queries; EDITED's complete historical archive, reaching back the full 12+ years, remains accessible via the API.

Two query tools cover this domain. They serve different query shapes and are complementary, not interchangeable.

market_data_options_search — row-level product data

Returns individual product options: specific items with their current price, stock status, discount depth, colour, sizing, and other attributes.

Use this tool when the question is about specific products: "show me", "list", "what are the cheapest", "find items where". Supports filtering by retailer, brand, category, colour, pattern, price range, discount depth, stock status, and more. Date-specific; covers up to two years back.

market_data_table — aggregated analytics

Returns computed aggregates: snapshots, breakdowns by dimension, cross-tabs, price histograms, period-over-period comparisons, and trends.

Use this tool when the question is about the market: "how many", "average price", "share by retailer", "how has this changed week on week". Supports grouping by retailer, brand, category, market, colour, and pattern. Up to three group-by dimensions in a single call.

Choosing between the two

A useful rule: if the user would want to see a table of individual products, use market_data_options_search. If they would want to see a chart or a summary statistic, use market_data_table. For the full decision guide, see How to query → Picking the right tool.

Verticals

Market data spans three verticals, and the API identifies them as apparel, beauty, and homeware — note homeware is the token the tools accept, though the vertical is described as "home" elsewhere.

A vertical is a top-level segment of the data, not a product category: categories like dresses or mascara sit within a vertical and are resolved with search_product_searches.

The vertical parameter is optional on market_data_options_search, market_data_table, search_product_searches, and get_retailer_coverage. Omit it and it resolves to your account's default vertical; pass it only when you specifically want a different one — and pass the same vertical across the tools in a workflow, so the categories and slugs you resolve match the data you query.

Access varies by account. All three verticals are visible to everyone in the tool schemas, but requesting one your account isn't entitled to returns an error. market_data_entitlements reports what you actually have:

• market_data_entitlements — returns the verticals this account can access, its default_vertical, and its default currency. Call it before offering vertical-specific analysis rather than discovering the limit through an error.

All three verticals return the same row grain — one row per product option. Homeware options bundle more SKUs per option (bed sizes, for example), so sku_count runs higher there; no vertical exposes per-SKU rows.

Field and metric reference

• market_data_docs — on-demand reference for the two query tools, one topic per call: filter_fields, metrics, group_by_fields, dates_and_compare, and text_search. Call it when you need an exact field id, metric id, valid value, operator, or price scale rather than guessing.

---

Trend & Research

Namespace prefix: researchmcp

EDITED's editorial content: trend reports, runway analysis, seasonal commentary, and market research articles. Semantic and paragraph-level search over the full library, with image retrieval.

The research tools follow a discovery → drill-down pattern. Start broad to find relevant reports, then go deeper into the specific passages or images you need.

Discovery

• research_article_search — semantic search returning one summary hit per report. The right starting point for any topic query. Returns report_id values you carry into the drill-down tools.

• research_list_reports — browse reports newest-first by publish date. Use when you want to know what exists in a date window rather than searching by topic.

• research_analyze_query — analyses a research query into retrieval intent (topics, article types, season, and so on) and, for a genuinely temporal phrase ("last 30 days", "Q3 2025"), an ISO date window. Optional and composable: the search tools accept those dates and intent axes directly, so reach for it when you want the parse done for you rather than as a mandatory first step. A bare year or season comes back as intent, not a date window — the search tools turn those into a range themselves.

Drill-down — text

• research_chunk_search — paragraph-level semantic search. Use after research_article_search, passing report_ids to search within specific reports. Returns granular passages with a session-scoped chunk_id.

• research_get_chunk — fetch a single text chunk by chunk_id. Cheap direct lookup; use within the same session as the search that returned the id.

• research_read_report — returns the full article body for a report_id. Use when the user wants to read or summarise a specific report. Prefer research_chunk_search when you only need specific passages — the full body is a large payload.

• research_get_report — lightweight metadata and excerpt for a known report_id. Cheaper than a full read; use when you need context without the full content.

• research_report_links — resolves report_id values to public EDITED Research URLs. Note: the public article page requires a user login to open.

Drill-down — images

• research_image_search — semantic search for images within articles. Good for visual and trend queries: "SS25 colour charts", "runway looks", "store window displays". Returns image URLs, captions, and session-scoped image_id values.

• research_match_images_to_text — given a block of text (typically an already-generated answer), finds images that visually support it. No date filter; use report_ids to constrain scope.

• research_get_image — fetch a single image by image_id. Pass include_bytes: true to receive base64-encoded bytes for multimodal model input.

---

Messaging & Promotions

Namespace prefix: messagingmcp

EDITED captures retailer homepages and marketing emails at regular intervals. This domain covers homepages and marketing emails only — not category landing pages or other messaging surfaces EDITED captures elsewhere. It exposes two indexes designed to be queried together: a visual and semantic index of the creative itself, and a structured index of promotions extracted from those captures.

Visual & messaging search

• messaging_search — semantic search over captured homepage and email screenshots. Returns OCR'd on-page text, a model-generated visual description, and image URLs. Use for creative context queries: "what is Zara saying this season", "which retailers are running summer colour stories", "what does H&M's homepage look like this week".

  By default returns only distinct creative (one result per chain head). Set include_repeats: true for date-precise queries where you need the capture nearest a specific day.

Promotions — structured queries

The four promo tools share a common filter vocabulary: retailers, regions, date range, promotion types, discount depth, whether a code is required, and whether inferred promotions are included.

• count_promos — count distinct promotions matching a filter. Accepts group_by (retailer, promo type, region, shoot) and interval (day, week, month) for bucketed results.

• list_promos — return individual promotions as examples, most-recent first. Use after count_promos to inspect what the aggregates contain. Returns up to 50 records with full promotion detail.

• aggregate_promos — compute mean, median, min, or max over promotion depth. Use for questions like "what is the average discount depth for UK fast-fashion retailers this month".

• search_promo_text — BM25 text search over free-text promotion fields (description, conditions, categories, promo codes). Use for fuzzy intent queries — searching for a specific campaign name or code string.

Cross-modal enrichment

• enrich_with_vm — given image_id values from promotion or messaging results, fetches the matching capture's full visual context: OCR text, visual description, and image URL. Use to ground structured promo results in the creative they came from.

---

Helpers

Namespace prefix: mdmcp

"Helpers" is a functional grouping — the identifier-resolution and data-quality tools that support a market-data query — not a separate backend. They are all Competitive Market Data tools, so their names carry the same mdmcp- prefix as the query tools (mdmcp-search_retailers, mdmcp-get_retailer_coverage) — there's no bare search_retailers on the wire. The table and prose below drop the prefix for readability, but the name you pass to tools/call always carries it. Call them before or alongside the domain query tools, not instead of them. The Trend & Research and Messaging & Promotions domains have their own resolution tools in their own namespaces.

Why identifiers matter

EDITED's query tools use stable internal identifiers — slugs and integer IDs — rather than free-text strings. Passing a free-text retailer name to a query tool will either fail or return unexpected results.

For retailers, always resolve the market first. Retailer slugs are not globally unique — the slug for Zara in the UK may be zara rather than zara-uk, depending on when the retailer was added to the system. Resolving the market first and then passing country_code to search_retailers is the reliable pattern. An agent that skips the market step and searches for a retailer by name alone may match the wrong regional storefront.

The typical resolution sequence for a retailer query:

1. Call search_markets to resolve the market ("UK", "US", "Germany")
2. Call search_retailers with the market's country_code to get the correct regional slug
3. Use that slug in downstream query tools

Identifiers are stable: resolve a concept once and reuse the result within a session rather than searching again. The identifier resolution tools support batch queries — pass a list of up to ten names in a single call.

For a full walkthrough of the resolution pattern, see How to query → Identifier resolution.

Data quality

• get_retailer_coverage — assess data completeness and freshness for one or more retailers over a date range. Returns gap summaries classified as no_data, low_volume, or high_staleness, along with healthy vs. total period counts. Scoped to Competitive Market Data (mdmcp) only — it does not report coverage gaps in Trend & Research or Messaging & Promotions.

  Call this before running analytics over any date window where data gaps would silently distort results. A clean aggregate from market_data_table can be wrong if the retailer had a coverage gap in that range — and the aggregate will not tell you this on its own.

Identifier resolution

Tool	Resolves	Returns
search_retailers	Retailer names to slugs	slug (e.g. zara-uk)
search_brands	Brand names to slugs	slug (e.g. nike)
search_markets	Market names to codes	id (e.g. UK)
search_product_searches	Product category names to IDs	id (e.g. 138)
search_size_group	Sizing system names to IDs	id (e.g. 43)
search_size_options	Individual size names to IDs	id (e.g. 901)

Crossing into the promotions domain. The market-data domain and the messaging/promotions domain use different retailer identifiers — a slug from mdmcp-search_retailers is not a valid promo filter. When you move to the promotions tools, resolve the retailer again in that domain with messagingmcp-list_retailers: match the name against the returned retailer_name, then pass that row's own retailer slug and a region it reports. Don't carry a market-data slug across the boundary.