How to list your MCP server on AWS Marketplace

Listing your MCP server on AWS isn’t really a submission. It’s closer to becoming a vendor. You register as an AWS Marketplace seller, you publish your server in the new AI Agents and Tools category, and if you want it to plug into Amazon’s agent runtime the way buyers expect, your OAuth has to work in a specific way most servers don’t support out of the box. It’s the heaviest lift on this whole list, and also the one that drops you inside enterprise procurement, where the buyers already have budget and a purchase process.

Worth a beat before the requirements. AWS is building serious plumbing so agents can reach tools at scale, and that’s real infrastructure. Remember what that plumbing carries. An agent calling your tools is only as reliable as the process telling it which tool to use, in what order, and when to stop and ask a human. The connection is infrastructure. The process is what makes it safe to automate, which is the longer argument across the AI and the future of work hub.

On AWS, listing your server means becoming a seller

AWS Marketplace added an AI Agents and Tools category that lists AI agents, MCP servers, and A2A servers side by side. To put anything there, you sign in through AWS Partner Central and create the product as a registered seller, which is the first real difference from Anthropic or OpenAI: there’s a commercial relationship before there’s a listing. In the wizard you pick a tool type, and “MCP Server” is one of the explicit choices, described in AWS’s own docs as “a server that manages communication and context exchange between AI models and applications.” You enter your endpoint URL, add usage instructions, and pick an auth method. Pricing is flexible and free listings are allowed, so reach doesn’t have to cost your buyers anything.

The catch isn’t the form. It’s everything the form assumes you’ve already built and registered before you reach it.

Two ways to put an MCP server on AWS

AWS gives you two listing models, and the right one turns on whether you already run the server. The first is a hosted SaaS or API-based product: you list the server you already operate and point AWS at its endpoint. For a cloud-hosted MCP server, that’s the natural fit, because nothing needs repackaging.

The second is a container that runs on Amazon Bedrock AgentCore Runtime. For an MCP server that route has a specific shape: an ARM64 Docker image, stateless streamable-HTTP, listening on port 8000, exposing a POST /mcp endpoint that answers tools/list and tools/call, per AWS’s runtime requirements. AgentCore is no longer a preview risk to plan around. It reached general availability in October 2025.

So the choice is simple. Already host a server? List it as SaaS and skip the container work. Don’t? The container path hands you a managed runtime to ship into.

The OAuth requirement that decides your path

Here’s the requirement that quietly decides how much work you’re in for. The strongest integration for an MCP server is Amazon Bedrock AgentCore Gateway, which turns your tools into something agents across AWS can call. The clean path into it has one condition. Per AWS’s gateway docs, if your MCP server “supports two-legged OAuth authentication, you can opt-in to offer your buyers the integration with no additional requirements,” and your MCP endpoint becomes the gateway target with no OpenAPI spec. If it doesn’t, you supply an OpenAPI specification instead. The server also has to advertise a supported protocol version, specifically MCP 2025-06-18 or 2025-03-26.

Two-legged OAuth is the catch. It’s client-credentials, machine-to-machine auth, a different grant than the three-legged user-consent flow most MCP servers ship for human approval. Tallyfy’s server is a tidy example of the gap: it runs OAuth the user-consent way, with authorization codes and dynamic client registration, which is exactly what Anthropic and Mistral want. AWS’s no-spec path asks for client-credentials on top of that, a grant plenty of hardened servers, ours included, would have to add.

So budget for it.

The OpenAPI route is the fallback if you’d rather not.

Who is the AWS Marketplace listing really for?

Enterprise buyers, mostly. If your users are individuals or small teams, Anthropic’s directory or a ChatGPT app gets you in front of them faster and cheaper. AWS is worth the lift when your buyers are companies that already purchase software through AWS, want it on their existing AWS bill, and run procurement that trusts the Marketplace by default. For that audience, sitting in the AI Agents and Tools catalog with a working AgentCore integration is a real edge in procurement, not a vanity badge. For everyone else, it’s a heavy build for reach you can get elsewhere.

The real test is timing. Do AWS when the enterprise pipeline justifies the seller registration and the two-legged OAuth work, and not a quarter before.

AWS rewards patience. Register as a seller, settle the hosting question, and plan for the two-legged OAuth work upfront, because that’s the real cost of the clean path. The payoff is a foot inside enterprise procurement, and that’s a deliberate, slow build rather than a weekend project. If your map also includes the consumer surfaces, the work you did here ports straight over: Claude’s directory and a ChatGPT app take far less setup than AWS, and the walkthrough of Tallyfy’s MCP server shows the build they reuse. For why the process around the tools, not the connection itself, is what makes an agent safe to turn loose, Tallyfy AI covers the guardrails.

AWS is the surface where “getting listed” looks most like a procurement project, because that’s what it is. The reward is a place in enterprise buying flows that no consumer directory can match. The price is seller registration, a real decision between hosting models, and an OAuth grant your server may not have today. Line those up in that order, and the heaviest lift on the list becomes the one that opens the biggest doors.