MCP
Reach a brand's catalog from an AI assistant, as the person using it.
The Fabric MCP server exposes a brand's catalog to an AI assistant through the Model Context Protocol. An assistant connected to it can search products, correct values, approve what enrichment wrote, move products through review and start exports. It acts as the person who authorized it, with exactly that person's permissions, and within the scopes they approved.
Not yet reachable
The server is built but not switched on yet. The endpoint starts answering once the connection details below are live. This page describes the server as it is built.
How it authenticates
The server uses OAuth 2.1, not an API key. An assistant has no credential of its own. It sends the user to Fabric, the user signs in and approves a list of scopes, and the assistant receives a token bound to that user, those scopes and this server.
As a result:
- A tool cannot do more than the person can. Every call uses the person's token and goes to the same API a person uses.
- The user approves each scope. The consent screen describes each scope in plain language, and the user can deny any of them.
- The token works only on this server. A token issued for another resource is refused, even if it is valid there.
Scopes
| Scope | What an assistant may do |
|---|---|
catalog:read | Read products, categories, attributes, views and lists |
catalog:write | Edit values, images and FAQ answers; move products through review; promote supplier-found data onto products, one credit each |
enrichment:write | Start enrichment runs, which spend credits |
publishing:read | See destinations, mappings and publishing history |
publishing:write | Publish to connected destinations |
org:read | See the organization and its brands |
org:write | Manage brands, members and keys |
Grant only the scopes the assistant needs. With only catalog:read it cannot change anything. The
tools published today need catalog:read or catalog:write (see Tools); the other
scopes are the API's and no tool here uses them yet, so granting them changes nothing until one does.
Brand IDs
There is no active brand and no default. A token identifies a person, and a person may belong to
several brands, so each tool takes an explicit brandId.
A brandId the user cannot reach returns not found, not forbidden, so the server never
confirms that an id exists.
Start with list_brands
It is the only tool that takes no brandId. It returns every brand you can act on, with the
organization each one belongs to.
Data Sourcing: plan, then start
Starting a supplier search is the one action here that leads to spending, so it takes two calls.
plan_data_sourcing costs nothing: it answers how many of the products you name can be sourced,
which cannot and why, and a quoteId. start_data_sourcing takes the same product ids and that
quote, and refuses when a fresh plan no longer agrees with it. Calling it again with the same quote
answers the run it already started.
The run itself spends nothing. What it finds waits for a decision: on the brand's Data Sourcing
review screen, which every reply links as reviewUrl, or through decide_data_sourcing_rows, which
promotes or demotes rows by observation id with a reason that is kept as the audit. A promotion
writes the page's data onto the product and costs one credit; a demotion of the page a product's
data came from removes it and refunds. get_data_sourcing_results lists the rows with their
evidence; get_data_sourcing_run and list_data_sourcing_runs report both readings of a run: the
grader's verdict per row, and how a person has since filed them.
Discovering the server
A client needs only the MCP endpoint URL and discovers the rest itself, as described in
RFC 9728. An unauthenticated request returns 401
with the location of the metadata:
WWW-Authenticate: Bearer resource_metadata="https://fabric.inc/.well-known/oauth-protected-resource/api/mcp"That document names the authorization server, the resource identifier your token must be bound to, and the scopes above. A compliant client needs nothing else from you.