Amazon’s Hackathon and Its MCP Track

Most hackathon tracks reward a well-designed wrapper around somebody else’s API. Amazon’s Build, Ship, Shape does not, in at least one place: the Alexa+ track asks for a self-hosted MCP server, which means an actual server you run, with a real transport, that an agent can call. That is a portable, verifiable skill rather than a certificate, and it is the reason this event is worth writing about despite not being student-only.

Submissions close 23 October 2026, 12:00pm PDT, judging runs 26 October to 20 November, and winners are announced 3 December. It is free, open to anyone above the age of majority in any country, and had 31,302 participants registered when we checked, so enter for the skill, not the odds. The four main tracks are Fire TV, Alexa+, Bee and Ring, with AWS Builder and Open Source mini-challenges alongside.

Table of Contents

The event

Deadline	23 October 2026, 12:00pm PDT
Submissions opened	31 August 2026
Judging	26 October – 20 November 2026
Winners announced	3 December 2026
Who can enter	Above the legal age of majority. Not restricted to students. All countries and territories except the usual Devpost exclusions
Cost	Free
Scale	31,302 registered participants at time of check
What you submit	A working demo, a GitHub repository, and a demo video under three minutes
Official site	amazonappdev2026.devpost.com

As stated on the Devpost event page, checked 5 October 2026.

It is the first global hackathon where Fire TV, Alexa+, Ring and Bee are all open to outside developers at the same time. Those are four constrained device platforms, which is the point: you are not building a generic chatbot, you are building something that has to work on a television, on a voice assistant, on a doorbell and on a beacon with limited memory and no browser to fall back on.

The Alexa+ track, and why it is the interesting one

This track requires a real self-hosted MCP server — to specification 2025-11-25 or later, using the Streamable HTTP transport — or an Agent Skill. Not a mock. Not a prompt file pointing at a public endpoint. A server you host.

That requirement is what makes this worth a serious afternoon, because the skill transfers. An MCP server is a defined interface: tools with schemas, a transport, and a server that owns its own authorisation. Once you have written one against a constrained device, writing another is a different afternoon rather than a different project.

It is also, at the moment, a genuinely useful thing to understand, because MCP servers are exactly where the security questions are. The most instructive vulnerability published in the last month was an argument-injection flaw in an MCP server where a value intended as a revision was parsed as a command-line flag, letting an attacker write files outside the sandbox the tool was supposed to be confined to. Building one is a good time to learn how they are supposed to be built safely: pass argument arrays rather than shell strings, pin argv[0], and validate at the boundary rather than trusting the caller. That is covered in the workspace-escape analysis, which is worth reading before you ship anything.

One practical warning. A self-hosted MCP server is a server, and a server on the public internet with a bad authorisation model is a liability. If you build one for this, keep it read-only where you can, scope its credentials tightly, and do not deploy it with a blanket permission just because the demo needed it.

The friction log, which most entrants will ignore

Optional friction logs can earn a 10% judging bonus. A friction log is a record of what went wrong during development, the failed approach, the bug, the assumption that turned out to be wrong — kept as you go.

Ten percent is significant, and the effort is small because the work is done anyway. Nobody succeeds for the first time. Keeping a running log while you build turns that into an artefact, and it happens to be the most useful thing you will produce after the repository itself. If you have never done this, this is a cheap way to start.

The mini-challenges

Two smaller ones run alongside the main tracks:

AWS Builder — the obvious fit if you are building on AWS and want the standard AWS track.
Open Source — the one to pick if you want something you keep afterwards. An open-source contribution made during the event is a portfolio artefact that a hiring manager can actually inspect, and it sidesteps the 31,000-person field entirely.

Is it worth entering at 31,000 participants?

Placing is a lottery at that scale and the prizes are not cash-heavy. Two reasons it is still worth it.

The Alexa+ track produces a real, portable skill. A working MCP server is a line on a CV that means something and demonstrably works.
Building for a constrained device forces good engineering. A television, a voice assistant, a doorbell and a beacon have no spare capacity and no browser. Whatever you learn making your project fit is the useful part.
The Open Source mini-challenge is judged differently from a lottery of 31,000 identical demos, and it is the one that leaves you with something permanent.

Enter with a scope you can finish. A narrow Alexa+ tool that genuinely works is worth more to you and, on a short judging list, more to the judges than an ambitious platform that half-runs.

If you want the events where you can actually place rather than the ones where you will learn the most, the round-up of student events open now separates the two. And if you are committing a weekend, read how to read a hackathon prize figure first — this event’s advertised total is not cash either.

We will add events as organisers confirm dates on their own sites. If you want the next round-up, the Events category collects every student event we have published, each with its official link and confirmed deadline.