[Template] ChatGPT Apps starter kit (Vite + React + HMR)

Erica Beavers — Tue, 28 Oct 2025 13:02:24 +0000

GitHub: https://github.com/alpic-ai/apps-sdk-template

OpenAI's ChatGPT Apps SDK lets you build interactive widgets that render inside ChatGPT using MCP. The initial template released a few weeks ago worked more or less, but the dev experience was rough. Every widget change required rebuilding the entire pipeline to get fresh assets.

That’s why built a starter template with HMR and a Skybridge framework to simplify the entire workflow:

What it includes:

Vite dev server with HMR running alongside your MCP Express server (one process, instant widget reload in ChatGPT)
Skybridge framework with file-based conventions that automatically map MCP widget endpoints to React components (name your endpoint pokemon-card, create web/src/widgets/pokemon-card.tsx, done)
One-click deploy to Alpic with bundling, hosting, and MCP analytics included, or to the platform of your choice No lock-in - built on the official @modelcontextprotocol/sdk

Quick start:

bash
git clone https://github.com/alpic-ai/apps-sdk-template
cd apps-sdk-template
pnpm install && pnpm dev
ngrok http 3000

Add https://your-url.ngrok-free.app/mcp to ChatGPT Settings → Connectors

Edit React components in web/src/widgets/ and see changes instantly in ChatGPT. No reconnecting, no rebuilding as the naming convention handles all the wiring automatically.

A few more details:

Skybridge's file-based convention: endpoint name must match widget filename (pokemon-card endpoint → pokemon-card.tsx component)
HMR updates widgets in real-time while MCP server keeps running
Production build compiles everything and deploys to Alpic in ~30 seconds

Plus, the sample app is Pokemon for a little nostalgia while you’re developing (you can thank us for that by starring in the repo!)

Happy to answer questions about the implementation or MCP integration patterns! And stay tuned for our next article that will offer insight on how we built the framework ;)

And a quick demo for the road:

Behind the Kiwi.com MCP server: building an agentic flight booking service

Erica Beavers — Wed, 27 Aug 2025 14:11:19 +0000

When Kiwi.com released their MCP server earlier this month, it became one of the first examples of agentic travel booking. This post covers how we helped them build it, what we optimized, and where we think there’s still room to improve.

If you'd like to try it out, the install guide is here: https://mcp-install-instructions.alpic.cloud/servers/kiwi-com-flight-search

Why MCP instead of APIs or scraping?

Scraping the UI: brittle, slow, and expensive (cookie banners, custom date pickers, JavaScript quirks).

Direct APIs: better, but not designed for LLMs. Hundreds of endpoints return too much irrelevant data, flooding context windows.

MCP provides a middle ground. It lets developers expose exactly the right tools, with guardrails, so the model can handle the task effectively.

Kiwi.com’s MCP server: first version

The current server exposes a single search-flight tool with the following parameters:

Trip type (one-way, round-trip)
Origin and destination (city or airport)
Dates with ±3 day flexibility
Passenger mix (adult, child, infant)
Cabin class

Each result comes with a direct booking link.

What we optimized with Alpic

1. One-click deployment & hosting

The server is deployed from a Git repo with standard build commands. Once pushed, it’s live on a secure HTTPS endpoint with a custom domain. Behind the scenes:

TLS termination and request parsing handled automatically
Tool execution in stateless, isolated environments
Built-in DDoS protection and rate limiting

This reduced Kiwi.com’s operational overhead so they could iterate quickly and expose the service to real users.

2. Server design choices

Shortened booking links: Long URLs eat context and risk breaking. We introduced shortened booking links to keep token usage small.

Structured responses: Instead of a free blob of text, the MCP instructs the LLM to return results in a table format, making comparison easier for users.

Fewer, curated results: Kiwi.com’s API can return thousands of flights, but the MCP server only sends a few dozen “best” options. This leverages Kiwi’s business logic while avoiding models making poor tradeoffs (like suggesting 15-hour layovers for €30 savings).

What’s missing and what’s next

Right now, the server only handles simple round-trip and one-way searches. Features not yet handled include:

Multi-destination itineraries
Checked bags
Max duration filtering
Account login and loyalty integration

On the protocol side, new MCP features could open up more options:

Elicitations: proactively asking the user to clarify (e.g. “Do you prefer Orly or CDG?” when searching Paris flights).

User preferences: storing seat choices, airlines, or price vs. comfort tradeoffs in reusable context.

Finally, better client-side capabilities will make adoption smoother: server registries (e.g. Claude Directory), less installation friction, and eventually end-to-end booking inside assistants without link redirects.

Takeaways

MCP servers are not just API wrappers, they require deliberate design for LLM usability.

Optimizing context usage (short links, curated data, structured responses) is critical.

Kiwi.com’s MCP server is an early step, but it shows how travel booking could work in an agent-native world. We'd love to have your feedback and ideas for future iterations.

Also, if you’re building with MCP and want one-step deployment, hosting, and AI-specific analytics, check out Alpic.ai.