Hello, Alexa-Ready

Bring your API. Alexa does the rest.

Inspiration

Alexa+ gets more useful with every service it can talk to. But getting onto it today takes custom integration work and knowledge of MCP (Model Context Protocol), which is a lot to ask of a dental office, a bistro or a local florist. Big brands can afford that work and small businesses can't. That leaves Alexa+ with fewer services, and customers can't reach the places they actually use.

We asked a simple question: what if a business only had to bring the API it already has?

What it does

Hello, Alexa-Ready is a platform that gets a business onto Alexa+ without code.

Business owners upload their API as a connector manifest. It's an OpenAPI description plus example voice phrases and account linking. Eight automated checks run on it, and the owner previews the tools it becomes.
Amazon reviewers try each tool against the business's real API with a test account, then approve it or reject it with a reason.
Alexa+ users find a service, connect with their own account, and publish it. We generate and host the MCP server once per service. They can then just ask in plain words.

The URL picks the service and the user's token picks the account. So every call runs as that user, and nobody sees anyone else's data.

The demo moment: in one conversation, Alice orders from Demo Bistro, books at Lakeside Dental, then checks her Bistro order again. Alexa switches services each time, and the trace shows which one answered. Three businesses, one conversation, none of them wrote Alexa code.

How we built it

Backend: FastAPI in one process, with Postgres for the service registry, user connections and submissions.
Pipeline: A manifest becomes a spec, then mapped endpoints, then one sanitized Python tool file per endpoint. Each file is checked by loading it, then stored as a numbered bundle version and activated on the gateway.
Gateway: POST /mcp/{service_uuid} is a standard MCP server (initialize, tools/list, tools/call). Each request goes through identity, a rate limit, an upstream allow-list, argument validation, the user's connection check and the user's own upstream token.
Auth: A demo login with JWT, an OAuth flow, and an encrypted token vault that refreshes tokens or marks a connection as expired.
Ask mode: The assistant scores every tool of every live service against the business's own example phrases and answer templates. It routes each turn by what the user said, not by the service used last. Writes ask for confirmation first. Nothing is hardcoded per business. An optional Bedrock LLM can replace the matching step.
Frontend: A React app with an Owner Portal, a Review Console and the Alexa+ app with a simulator.
Mock services: Demo Bistro, Lakeside Dental, Lakeside Grill, Pine & Petal and a fake OAuth provider, all in Docker Compose.

Challenges we ran into

Per-user identity at scale. One shared server has to act as many different users, so each call has to use that person's own token. We handle refreshing and expired connections without leaking anything.
Keeping IDs from crossing services. An order_id remembered from the Bistro must never be offered to the Dental tool, so we keep what the assistant remembers separately for each service.
Switching topics mid-chat. A pending "Should I book that?" belongs to its service and has to be dropped when the user changes topic. Ambiguous names like "Lakeside" (Dental or Grill?) have to prompt a question and not a guess.
Running generated code safely. We build tool files from sanitized templates and check names, paths and types before anything is loaded. The gateway also has rate limits and an upstream allow-list.
Alexa+ access. The Alexa+ MCP toolkit is partner-only, so we built everything up to that boundary and mocked the registration step.

Accomplishments that we're proud of

A full path from a business's API to a working, per-user MCP server, with review in the middle.
Adding a new service needs no change to the assistant. Once it's approved and published, it works in chat.
Updates are handled. When a business ships a new version, users see "Update available" and the old version stays live until the new one loads.
One script, scripts/e2e_check.py, runs the whole flow over HTTP against the running stack.
The simulator trace makes the platform visible. A judge can watch each turn switch MCP servers live.

What we learned

The hard part of onboarding isn't the API call. It's identity, consent and trust. Getting those right is what makes it safe for small businesses.
A business's own example phrases and answer templates carry enough information to route requests well, even without an LLM.
Showing the work, with traces, review steps and clear "blocked" messages, makes a platform much easier to trust.

What's next for Hello, Alexa-Ready

Real Alexa+ registration once partner access is available. The MCP URL already works with any MCP client.
Alexa account linking to replace the demo username login.
LLM intent routing in production as the default, with the rules as a fallback.
AWS deployment on EC2, with S3 bundles, Secrets Manager tokens and SES email. It's implemented and tested but hasn't run on EC2 yet.
Onboarding more businesses, with self-serve manifest tools so an owner can go from API to Alexa+ in minutes.