Amazon Vendor Central MCP: What Exists for Vendors Today

Someone on your team has connected Claude or ChatGPT to a few business tools, and the next question is obvious: can it read our Vendor Central data? Search for an Amazon Vendor Central MCP and most of what comes back is written for third-party sellers. Amazon did release an official MCP server this fall, and it's easy to read that news as covering vendors too, but it doesn't. Below is what Amazon released, why it stops at Seller Central, the two kinds of vendor-side options you can use today, and what any of them will need from your team before an agent can read a single PO.

Does Amazon Have an MCP Server for Vendor Central?

No. Amazon's official MCP server, the Selling Partner Connector, works through Seller Central. Its documentation grants access through "the standard Seller Central OAuth consent flow" and limits the agent to "the tools your Seller Central roles allow," and Vendor Central doesn't appear anywhere in it (Amazon's toolkit on GitHub). If your business sells to Amazon through Vendor Central alone, there's no consent flow in that documentation for you to complete.

What vendors can use today comes from two places: a sample server published by AWS that you run yourself, and commercial servers built on the vendor side of the Selling Partner API. Each one reaches a different slice of your data, so it's worth knowing which slice before you connect anything.

What MCP Is, Briefly

MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems, so an assistant like Claude or ChatGPT can read data sources and call tools through one consistent interface (modelcontextprotocol.io). An MCP server sits between the assistant and a system such as the Selling Partner API (SP-API). It exposes a set of tools, like "get purchase orders" or "run a sales report," and the assistant decides which ones to call to answer your question.

For a vendor, the appeal is asking "which POs from this week haven't been acknowledged yet?" in a chat window and getting an answer pulled straight from Amazon, with no report download in between. Whether you get that answer depends on which tools the server exposes, and that's where the options below differ.

What Amazon Shipped, and Where It Stops

Amazon announced agent access to seller tools at its Accelerate conference in September 2026, starting with Amazon Quick and a beta with Claude in Amazon's U.S. stores (API Evangelist). The connector is hosted at sellingpartner-ai.amazon.com/mcp, and the open-source toolkit around it packages agent skills for common account jobs (GitHub). The launch skills cover:

listings troubleshooting
buyability and searchability
compliance pre-flight checks
stockout prevention
the full FBA inbound workflow
seller analytics
support cases
inviting secondary users
SP-API developer questions

Write actions are always drafted for approval, and the assistant can only use the tools the account's Seller Central roles allow. An account admin manages agent access from a Manage Agents page in Seller Central (API Evangelist).

Every skill on that list maps to a Seller Central job. None of them touches purchase orders, invoices, shortage claims, or Retail Analytics, which is where a vendor team actually spends its week.

If you came from Seller Central: a hybrid business with both a seller account and a vendor account can use the connector on the seller side. The vendor side is a separate set of SP-API operations, covering Retail Analytics reports, Retail Procurement, and Direct Fulfillment, and the connector's documentation never mentions any of them. Don't expect a seller-side skill to have a vendor equivalent waiting behind it.

What Vendors Can Use Today

In practice you're choosing between running a sample yourself and paying for a server someone else maintains. That's the same build-versus-buy decision our Vendor Central API guide walks through for raw API integrations, with an AI assistant on top.

The AWS sample server: yours to run

AWS publishes a sample SP-API MCP server in its aws-samples organization, and the README is direct about what it is: "a prototype/proof-of-concept and is NOT a production-level application," intended for local development, testing, and demonstration (aws-samples on GitHub). It runs locally through Node.js on the machine of whoever sets it up.

Its vendor coverage is thin: against roughly 30 seller-side tools, about 6 are vendor-side, and they cover three Retail Procurement jobs:

Vendor Orders: retrieve purchase orders and acknowledge them.
Vendor Shipments: submit shipment data.
Vendor Invoices: submit invoice information.

The README doesn't mention Retail Analytics reports or Direct Fulfillment. An agent connected to this server can find a PO and acknowledge it, but it can't answer a question about sales, traffic, inventory, or Net PPM. Treat it as a way to watch an agent work against your own procurement data in a test setup, with an engineer driving.

Commercial vendor MCP servers: someone else maintains it

Commercial servers built for vendors cover more of the SP-API vendor surface. Kuudo's Amazon Vendor Central MCP is one example, and its published coverage spans three areas (Kuudo):

Retail Procurement: PO acknowledgements, cancellations, change orders, shipment requests, labels, invoices, and transaction status.
Direct Fulfillment: orders, shipping labels, container labels, packing slips, inventory updates, payments, and transaction tracking.
Analytics: Data Kiosk queries and Vendor Retail Analytics covering sales, traffic, inventory, forecasting, and net pure margin.

It works with Claude, ChatGPT, Cursor, Gemini, Perplexity, and coding tools such as Claude Code and Codex, and it supports 22 marketplaces across North America, Europe, and Asia-Pacific. You choose between a managed server Kuudo hosts and running it in your own private cloud. It's in private beta, and pricing isn't published.

Which one fits

Run the AWS sample yourself if all of these are true:

You have an engineer who can register an SP-API application and own its credentials.
The questions you want answered are about POs, shipments, and invoices.
You're testing whether an agent is useful before anyone signs a contract.

Look at a commercial server if any of these are true:

You want the agent reading Retail Analytics, Data Kiosk, or Direct Fulfillment data.
You need it running for a whole team every day, outside one engineer's laptop.
You'd rather someone else keep the server current as Amazon changes the API.

What Any of These Need From You

Every option above reaches your data the same way, through SP-API credentials authorized for your vendor account. The AWS sample needs an LWA (Login with Amazon) client ID, client secret, and refresh token, and Kuudo authenticates with vendor-scoped LWA credentials. Getting them takes the same registration a raw API integration needs: the primary account user on the Vendor Central account registers as a developer, registers an application, and requests roles. The Vendor Central API guide covers that sequence and the vendor roles list, so we won't repeat it here.

Before anyone opens the developer portal, settle three things:

Who holds the credentials. Name the person who owns the application and the refresh token, and who takes them over if that person leaves.
Which roles the agent gets. Roles gate specific sets of operations, so request only the ones the agent's questions require. Reading reports and touching POs are separate jobs, and an agent that only answers sales questions doesn't need the PO roles.
What the agent may write. Amazon's own seller connector drafts every write for human approval. Hold a vendor setup to the same rule, especially for anything that acknowledges a PO or submits an invoice.

What an MCP Server Still Can't See

An MCP server can only return what the API behind it returns, so the limits of the Vendor API carry straight through to the agent. No vendor report type covers who holds the buy box, which third-party offers sit on your ASINs, or when your detail page content changes, because that information lives on the public Amazon.com product page. Each report also has its own lookback window, so an agent asked about two years of weekly sales can only answer from history someone has already stored (Vendor Central API guide).

An assistant connected only to SP-API won't see any of that.InsightLeap ingests Amazon Vendor Central, Amazon Advertising, and Amazon.com and puts them in one dashboard, so buy box and listing changes from the product page show up beside your Retail Analytics numbers.

Where This Leaves Vendors Today

For now, an agent that reads your Vendor Central data will come from a third party or from your own engineers. Write down the questions you want it to answer first, then check that the server you're evaluating exposes the API operations behind them. Once that lines up, settle the credentials and roles with your primary account user before anything gets connected.