Example workflow

A worked example showing how an agent uses EDITED MCP end-to-end. The user asks a fuzzy retail question; the agent uses MCP tools to resolve fuzzy concepts to stable IDs, then feeds those IDs into the market-data tools to fetch the answer — all over the same MCP connection.

The scenario

"Compare dress assortments at Zara and H&M in the UK over the last quarter."

To answer this, the agent needs three things from the EDITED catalogue:

1. Stable retailer slugs for "Zara" and "H&M" — and only the UK storefronts
2. A product-category ID for "dresses"
3. A market ID for the UK market

It can't guess these. They live in EDITED's taxonomy, behind MCP.

Step 1 — Resolve the retailers

const result = await client.callTool({
  name: "mdmcp-search_retailers",
  arguments: {
    query: ["Zara", "H&M"],     // batch — both at once
    search_limit: 3,
    country_code: "UK",
  },
});

const [zaraMatches, hmMatches] = JSON.parse(result.content[0].text);
// → zaraMatches[0]: { name: "Zara", slug: "zara-uk", region: { iso_code: "GB", ... }, ... }
// → hmMatches[0]:   { name: "H&M",  slug: "hm-uk",   region: { iso_code: "GB", ... }, ... }

const retailers = [zaraMatches[0].slug, hmMatches[0].slug];

The agent picks the top match for each query. Note we batch both queries in a single call — faster, fewer round-trips, less context burned.

Step 2 — Resolve the product category

const result = await client.callTool({
  name: "mdmcp-search_product_searches",
  arguments: { query: "dresses", search_limit: 3 },
});

const categories = JSON.parse(result.content[0].text);
// → categories[0]: { id: 138, name: "Dresses", category: "dresses", vertical: "apparel", ... }

const categoryId = categories[0].id;

Step 3 — Resolve the market

const result = await client.callTool({
  name: "mdmcp-search_markets",
  arguments: { query: "UK", search_limit: 1 },
});

const markets = JSON.parse(result.content[0].text);
// → markets[0]: { id: "UK", name: "United Kingdom (UK)" }

const marketId = markets[0].id;

Step 4 — Query the data

With three resolved identifiers, the agent runs the comparison with market_data_table — another MCP call, so there's no separate API to wire up. The resolved slug and id values go straight in as filters:

const result = await client.callTool({
  name: "mdmcp-market_data_table",
  arguments: {
    retailers,                      // ["zara-uk", "hm-uk"]  (step 1)
    product_search_id: categoryId,  // 138                   (step 2)
    market_id: marketId,            // "UK"                  (step 3)
    date_range: "last_quarter",
    metric: "avg_price",
  },
});

const data = JSON.parse(result.content[0].text);
return data; // ← what the agent presents to the user

See How to query → Picking the right tool for the full market_data_table grammar — metrics, group-by, histograms, trends, and period-over-period comparisons.

Why resolve IDs first?

You could ship every retailer slug, category ID, and market ID into the agent's system prompt. That doesn't scale — EDITED has thousands of each, and they change weekly.

Resolving on demand lets the agent look them up the same way a junior analyst would: ask "what's the slug for Zara UK?", get the answer, then query the data — every step over the same MCP connection. The agent stays small and current; the catalogue stays in EDITED's source of truth.

Patterns to steal

• Batch parallel resolutions. When the agent needs two or three lookups to answer one question, batch them in a single tools/call with a list of queries. EDITED MCP runs them concurrently.
• Always pick the top match for fuzzy queries. Vector search ranks by semantic similarity. The first hit is usually right; if it isn't, your query was ambiguous.
• Log the slugs/IDs the agent resolves into. That's what you'll need when reproducing a session for debugging.