Build the app in Codex. Create its media with Rubiic.

You are building a web app in Codex. The booking flow works, the layout is taking shape, and the hero still contains an empty rectangle where a product animation should be. That rectangle needs its own brief, a preview, a revision and a file you can actually ship.

Connect Rubiic through MCP and you can handle that work from the same Codex conversation. Codex builds the application and passes a media brief to Rubiic. Rubiic authors the animation and exports it; Codex downloads the result and places it in the page.

Here is a walkthrough using a fictional appointment-booking app. The prompts are examples you can adapt, not a transcript of a completed build. The aim is a useful handoff: one working application, one small animation, and the assets needed to show it well.

Start with the app and the space the asset needs to fill

Give Codex the application task first. It needs enough context to build something the animation can explain. For this example, the core interaction is choosing a service, picking an available time and confirming a booking.

Build a responsive appointment-booking web app with a landing page and a working demo booking flow. Use local sample data. Visitors should be able to choose a service, select an available time and see a confirmation. Use a navy background, white text and cyan accents. Leave a 16:9 space beside the hero copy for a short product animation.

Work through the interaction before making the media. If the app cannot reschedule a booking yet, its animation should not advertise rescheduling. Have Codex summarize the features that actually work and extract the page's colors, visible labels and intended media dimensions. Those become the brief instead of a second, slightly different product description written from memory.

The animation also needs a job. Here, it should let a visitor understand the three-step booking flow before trying it. Keep the headline and booking button as ordinary page elements so they remain readable, selectable and usable independently of the video.

Connect Rubiic to Codex

You need a Rubiic account with access to create media and an API token from your account page. The MCP setup guide has a Codex tab. Its personal configuration goes in ~/.codex/config.toml:

[mcp_servers.rubiic]
url = "https://rubiic.com/api/mcp"
http_headers = { Authorization = "Bearer YOUR_RUBIIC_TOKEN" }

Replace the token placeholder in your personal configuration. Keep the real token out of your app's source, browser code and committed files. Restart Codex, check the MCP server settings or run codex mcp list, and ask for a read-only check:

Use Rubiic to list my projects so I can check the connection. Do not create or render anything yet.

An empty project list is fine for a new account. An authentication error needs fixing before you start creation. OpenAI's Codex MCP documentation covers the client configuration; the Rubiic guide covers the server address and token setup.

This connection gives your coding assistant access to Rubiic. Visitors to the booking app will play exported files; they do not need a Rubiic account or an MCP connection.

Give Rubiic an asset brief from the build

Ask Codex to carry the app context into the request. Rubiic does not automatically see your repository or a development server running on your laptop. Include the important details explicitly, and use public reference pages or pasted text when you need supporting context.

Use Rubiic through MCP to create an eight-second, silent product animation for the booking app we are building. Use 1280 × 720 at 30 fps. Show three beats: choose a service, choose a time, then see “Booking confirmed”. Use the current page's navy and cyan colors; include their exact values and the app's labels in your brief. Use a simplified interface with large text. Keep the final confirmation visible long enough to read. Propose the sequence first, and ask me before rendering or exporting files.

The simplified interface matters. Rubiic authors a composition for the brief; this request is an illustrated explanation of the flow, not a recording of the live application. If exact interface fidelity matters, review the labels, layout and behavior against the app. A palette in the brief is guidance to inspect in the result, too.

Creation runs as a Rubiic task. Codex starts it, checks its status and brings back questions or approval requests. A pending task means work is still underway, not that the finished MP4 already exists. You can ask Codex to continue independent layout work while it waits, then return to the media decision when Rubiic needs input.

Review the animation in the page's context

Judge the preview at the size it will occupy. Text that is clear in a large player may be unreadable in a narrow feature card. Look for a clear sequence, enough time to read each beat, and a final state that makes sense when the motion stops.

Open the project in Rubiic when you need its visual workspace. The conversation can stay in Codex, but watching the actual output is part of choosing it. Do not treat a successful tool response as a visual review.

Revise the existing Rubiic animation: make the service labels larger, simplify the time picker to three visible slots, and hold “Booking confirmed” for the final two seconds. Keep the eight-second duration and current palette. Show the revised preview before exporting.

Send that feedback while Rubiic is waiting for a review response. MCP's agent_update answers pending input requests; it does not reopen a completed task for arbitrary follow-ups. If the task has already completed, open the existing project in Rubiic to request the revision. Keep the project reference so Codex can retrieve its scenes afterward. Rubiic saves revisions as new versions; check the revised scene before exporting it, because an earlier MP4 still contains the earlier design.

Turn the approved scene into the assets the app needs

For this page, three deliverables cover different placements. They can all come from the approved scene, which gives you a common starting point for their composition and colors.

• An MP4 for the hero. The complete eight-second animation explains the booking flow in motion.
• A WebP poster. A readable frame from the confirmation hold gives the player an image before playback and the page a still alternative.
• A GIF for a compact feature card. A short selection of the animation can demonstrate the time picker in a smaller placement, if it remains legible.

Export the approved scene as an MP4. Also export a WebP still from a fully visible frame during the confirmation hold, and a looping GIF of the time-selection beat at 320 px and 5 fps. Check the saved scene's duration and frame rate before selecting frames. Wait for each export to succeed, then download the files into the app's public/media folder.

Rubiic's MCP tools separate creation from delivery. Codex reads the project's saved scenes with get_project, requests the MP4 with start_render, and uses start_export for the still and GIF. It checks the corresponding status tools before requesting a file through get_download_url.

This distinction prevents a common handoff mistake: a scene preview is not a downloaded video. Generation and rendering use credits, as do image, GIF and carousel exports. Make the requested outputs explicit and check your account's available usage before starting.

The download URLs expire. Ask Codex to save the returned bytes promptly, check that they are valid media files, and use stable paths in your app or media hosting. If a link expires, request a fresh download URL for the successful job rather than rendering the scene again.

Let Codex handle the final integration

After the files arrive, the task returns to application work. Give the assets descriptive filenames and connect them to the places you reserved. A useful follow-up prompt is:

Add the downloaded MP4 to the hero with its WebP poster, visible playback controls and inline playback on mobile. Keep it click-to-play with preload set to none. Reserve its 16:9 space to avoid layout shifts. Use the still for reduced-motion visitors instead of starting animation. Add the GIF to the feature card only if its text is readable at the displayed size; use a still there for reduced motion. Test both desktop and mobile layouts.

Codex now has concrete files to integrate. Review the application with those files in place: does the poster explain anything before play, does the video fit without cropping important labels, and does the booking button still get enough attention? Check keyboard access to playback controls and that the page works when someone never plays the video.

Also inspect the downloaded file sizes and the network requests. A valid export can still be too heavy for its placement. If the GIF is large or hard to read, keep the MP4 in the main player and use the still in the card. Those are decisions about the finished page, not just about whether a render succeeded.

What else fits this workflow?

The same handoff can support an onboarding explainer, an animated process diagram or a narrated feature walkthrough. Rubiic can generate images for a composition as well as author its text and motion. Describe the asset's purpose and placement, then choose a supported export for the application.

• Still images: PNG, JPEG and WebP from selected scene frames for posters, illustrations and feature cards. Check the actual background; do not assume transparency.
• Short loops: GIF selections up to ten seconds, with 320 or 640 px maximum side and 5 or 10 fps options. GIFs are silent.
• Step-by-step material: carousels of up to twelve selected frames, delivered as a PDF and an ordered PNG ZIP.
• Caption files: SRT or WebVTT when the scene has timed narration. The silent booking animation does not have narration to caption. Caption exports are free.

Rubiic authors rendered media. This workflow does not deliver an interactive booking widget, a Lottie file or generated cinematic footage. Codex still builds the interface, its state and its accessibility; Rubiic supplies the visual explanation that sits within it.

Start with one asset that helps someone understand your app. Build the interaction, brief the animation, review a revision, export the files and place them in the real layout. The MCP guide gets the connection ready, and our published examples show actual Rubiic outputs and the checks recorded for them.