A³ Live Representative

One MCP server that puts local businesses' own live video representatives on Alexa+: a real face on the Echo Show that answers and books.

Comment

Try it: alexa.triplea.studio · Code (MIT): GitHub · Video: YouTube

Inspiration

Alexa+ is opening to third-party MCP servers (in Preview), and the first brands building add-ons are big ones, in travel, rides, tickets and more. They can afford to build and certify their own MCP server. A laser clinic in Austin, a barber, a yoga studio can't, and never will. So when you ask Alexa for a local service, the best it can do is read out a list.

We build A³ (Triple A): a business sets up its own live video representative, a real-time talking avatar with the business's face and voice, its prices, answers, rules and calendar. We asked: what if one MCP server put every one of those representatives into Alexa+ at once?

What it does

You ask Alexa for a service. Alexa finds nearby businesses through our MCP server and says that one of them has a live representative. Say "yes", and the business's representative appears on the Echo Show screen and greets you in voice. You talk to her as you would at the front desk: prices, whether it hurts, how many sessions. Then "book me for Saturday at ten", and she books you herself. Alexa already knows who you are, so it passes your name and phone along with your words, and nobody asks you to spell anything. After you say goodbye: "Alexa, add it to my calendar", and Alexa pulls the confirmed booking over MCP and saves it.

For Alexa, that means:

  • businesses on A³ without integrating them one by one: each business sets itself up in A³; the MCP server stays the same;
  • a real face on the Echo Show screen instead of a list read aloud;
  • questions that turn into bookings without leaving Alexa, with the result handed back to the assistant's calendar.

Demo scope: the catalog is three fictional Austin clinics, each mapped to a representative set up on the A³ platform; the user profile is a fixed demo profile, and the calendar is the simulator's stand-in. Reading the A³ business directory instead of a file is the next step.

How we built it

  • MCP server (TypeScript, official @modelcontextprotocol SDK v2, Streamable HTTP, spec 2025-11-25) with five tools: find_providers, talk_to_representative, ask_representative, get_representative_booking, book_appointment. Every tool has an outputSchema and returns structuredContent.
  • MCP Apps views built to the Alexa+ add-on rules: each a single self-contained HTML document (libraries inlined, no external fonts) for a sandboxed iframe; network declared in _meta.ui.csp; host communication only through the MCP Apps bridge. The representative view plays WebRTC video and voice (LiveKit) with subtitles.
  • A relay on the MCP server connects the sandboxed view to the A³ platform and sets the session parameters on the server side, so the view never holds them.
  • Voice-host mode. On a real Echo Show, web pages get no microphone (see the friction log), and Alexa already listens, so Alexa stays the ears: ask_representative passes the user's words into the live session and the representative answers on screen. In hosts that grant the microphone, the same view talks to the user directly; we tested the live conversation window in Claude and ChatGPT.
  • Booking hand-off. The representative confirms a booking inside A³; the relay keeps it, and get_representative_booking gives it back to Alexa for its calendar.
  • Alexa+ simulator. Alexa+ add-ons are partner-only, so we built an Echo Show style simulator: speech recognition, an LLM playing Alexa with function calling (Gemini Flash), Alexa's voice (ElevenLabs), follow-up mode, and a real MCP client plus the MCP Apps host bridge. Every business action in it is an MCP tool call to our server; only the representative's video and voice stream over WebRTC.
  • Public endpoint for judges on AWS (EC2 Graviton, Caddy with TLS): one live conversation at a time, a time limit, and rate limits, since every conversation uses a real GPU avatar slot.

Challenges we ran into

  • No device access. Alexa+ for Builders is partner-only and the CLI is not on public npm, so we could not deploy to our own Echo Show. We followed the written add-on rules by hand and tested the views in two other MCP Apps hosts.
  • The microphone. We expected to let the user talk to the representative inside the view. In the Echo Show's browser, getUserMedia fails instantly with no prompt, and so do Web Speech and the camera. That turned into the core design: Alexa listens, the representative speaks.
  • Opaque origins. A sandboxed view sends Origin: null, which a real-time backend can't trust. We moved the trust decision to our own server: the relay sets the session parameters itself and limits concurrent conversations, their length and request rates.
  • Who books. Our first version had Alexa book. That was wrong: the business's representative knows the rules and the calendar, and Alexa knows the user. Splitting the roles that way made the flow shorter and the booking correct.

Accomplishments that we're proud of

  • A live video representative inside an assistant's MCP Apps view, answering in voice within seconds of the question.
  • One MCP server and one conversation window that also ran as an MCP App in Claude and ChatGPT, not just in our simulator.
  • A booking made by the business's own representative and handed back to the assistant, with the user never asked for their name.

What we learned

  • On voice-first devices, the assistant should keep the ears and the business should get the face. Designing for that made the add-on simpler, not weaker.
  • MCP Apps is enough to bring a full real-time experience into an assistant, as long as the server takes on the parts a sandbox can't (origin, session parameters, state between calls).

What's next

  • Real availability and booking through the scheduling systems businesses already use, instead of demo businesses.
  • Alexa+ certification as soon as add-on access opens, and listing in the Claude and ChatGPT app directories.

Project history

A³, the avatar platform, existed before the hackathon and is used here as a hosted service. Everything in the repository was built from October 1, 2026, for this track: the MCP server and its five tools, the three MCP Apps views, the relay, voice-host mode with ask_representative, booking by the representative with hand-off to the assistant's calendar, the Alexa+ simulator, and the protected public endpoint.

Friction log

Five entries with steps, expected vs actual, severity, workaround and suggestion: FRICTION_LOG.md. In short: partner-only access, a CLI that can't be installed, silent microphone denial on Echo Show, opaque-origin views vs backends that check Origin, and no guidance for handing results back to Alexa's own features.

Built With

Share this project:

Updates

Submission history