Using MCP and the API together

The chooser helps you pick one surface for one job. This page is the other half of the story: for a lot of builders, EDITED MCP and the REST API are strongest together. You don't have to choose one and live with it.

The REST API is how you land data at scale — bulk pulls, pipelines, exact aggregations in your own systems. That doesn't change. What changes is the parts around the pipeline that have always been fiddly: getting the setup right, confirming what landed, and answering the questions your data raises but can't itself answer. Those are the parts a little MCP assistance makes dramatically easier — and you can add it without rebuilding anything you've already got.

If your team hasn't adopted AI tooling yet, MCP is a low-risk place to start: the two quick wins below are everyday integration chores, not a new way of working, and (as the third section explains) you don't have to put a model anywhere near your pipeline to get them.

Quick win 1 — resolve identifiers by conversation

Most of the effort in standing up a REST pull is up front, and it's the same effort every time you expand the pipeline: the filters expect EDITED's exact slugs and IDs, not free text, so before anything returns you have to resolve the retailers, categories, brands, and sizes you care about into the identifiers the API accepts. Guess a name and you get an error — or worse, the wrong retailer's data and no error at all.

MCP turns that lookup into a conversation. The search_* tools (search_retailers, search_brands, search_product_searches, and the rest) are vector search — misspelling-tolerant, phrase-friendly — so you can ask for "that French boutique label" or "lululemon" and get back the resolved identifier. market_data_docs answers "what values does this filter accept?" in the same place, instead of sending you to a separate reference.

The identifiers are the same on both surfaces, so once you've resolved them over MCP you drop them straight into your REST filters. Resolve once, cache what you got back, reuse it across the pipeline — exactly the learn-once habit that keeps the rest of your integration cheap. It's a common, fully supported pattern, not a workaround.

The full mechanics can be found in Filters → Resolving values and How to query → Identifier resolution.

Quick win 2 — set expectations, then verify what landed

Most teams already run their own quality checks on what they pull — did the pull land everything it should have, is this retailer fully crawled for the window — and when a check trips, they open a ticket for EDITED to investigate. That process works; it's just reactive, with a natural lag between a gap appearing and an answer coming back. A homegrown check also can't easily tell you one thing on its own: when a pull comes back thin, whether EDITED's crawl was short for that window or something downstream in your own pipeline dropped it.

EDITED MCP lets you get ahead of some of that. get_retailer_coverage reports how complete and fresh EDITED's data is for a retailer over a date range, classifying each period as no_data, low_volume, or high_staleness. Run it before a pull to set an expectation for what's actually available in the window, and after to confirm what you landed lines up — alongside your existing checks, not in place of them, and perfectly usable even when every byte you ship comes over REST. market_data_entitlements confirms what your access covers. It's the same signal EDITED reaches for first when a coverage question comes in, so you get that first look straight away — and arrive with a sharper question if you do raise a ticket.

See How to query → Coverage checking for when it matters most, and the coverage tip on Granularity for a worked case.

You don't need to put a model in your pipeline

It's a reasonable assumption that reaching MCP means wiring an LLM into your stack — and for a team that hasn't adopted AI, that sounds like a bigger commitment than the win is worth. It isn't the case. MCP is a protocol: a server exposes tools, a client calls them. Your own code can call get_retailer_coverage or a search_* tool directly, with arguments you already know, and get the same result every run — no model deciding anything.

So the two wins above are available to you as ordinary, deterministic function calls today. A model earns its place only when the right tool or arguments genuinely depend on something you learn at runtime — and that's a step you can take later, or never. Start with the direct calls.

You can watch one happen right now: every tool page in the MCP Reference has a Try it widget that fires the call straight from your browser, with nothing but your own inputs deciding it. (Drop in your access key and it returns live data.)

The two ways to call a tool, and when each pays off, are covered in How to query → Calling a tool doesn't require a model.

Going further — ask questions the API can't

The two quick wins make the pipeline you already have smoother. The larger opportunity is what MCP lets you add to it.

Your REST pipeline reaches Competitive Market Data. EDITED's Messaging & Promotions and Trend & Research have no REST surface — MCP is the only programmatic route to them. A competitor-monitoring pipeline built on REST already tells you what retailers are selling, and at what price; through MCP you can extend it to ask what they're promoting and how they're saying it, and what the research context around it is — questions the market-data pull can't answer on its own. (What your access reaches across these domains depends on your entitlements.)

You don't have to design that in advance. Because MCP is conversational, it's a good place to explore whether a question is worth operationalising before you build anything for it — prototype the question, then decide what, if any, of it earns a place in the pipeline.

One thing to know when you cross domains: a retailer identifier from the market-data tools isn't valid in the promotions tools — the domains identify retailers differently, so re-resolve when you move. That (and the other cross-domain gotchas) is on Before you build; the chooser has the surface-by-surface breakdown of what each one reaches.

Where to go next

If you want to…	Read
Decide which surface fits a single job	MCP or the API?
Resolve filter values over either surface	Filters → Resolving values
Follow the identifier-resolution sequence	How to query → Identifier resolution
Check a date window's coverage	How to query → Coverage checking
Call an MCP tool from your own code, no model	How to query → Calling a tool doesn't require a model
See the gotchas that bite cross-surface builders	Before you build
Make your first MCP call	Quickstart
Browse the REST endpoints	API reference