@runapi.ai/gemini-omni-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RUNAPI_API_KEY | Yes | Your RunAPI API key |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| loginA | Authenticate RunAPI by opening a browser PKCE login flow and saving the API key to ~/.config/runapi/config.json. |
| text_to_videoA | Create a Gemini Omni task on RunAPI (text to video). Returns a task id, status, and output URLs. |
| create_audioB | Run a synchronous Gemini Omni operation on RunAPI (create audio). Returns the operation result. |
| create_characterB | Run a synchronous Gemini Omni operation on RunAPI (create character). Returns the operation result. |
| get_taskA | Fetch the current status and latest result payload for a gemini-omni task. |
| check_pricingB | Look up RunAPI pricing for the gemini-omni model line. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct operation: video creation, character creation, audio creation, pricing lookup, task status fetch, and authentication. There is no ambiguity between them, as the action and resource are clearly separated.
Most tools follow a verb_noun pattern (create_character, create_audio, check_pricing, get_task), but text_to_video is a descriptive noun phrase rather than a verb, and login is a single verb. These minor deviations are still readable and predictable overall.
With 6 tools, the server is well-scoped for a media generation API. It covers creation, status tracking, pricing, and authentication without unnecessary bloat or redundancy.
The tool surface covers the core lifecycle: creating various media types, retrieving task results, checking pricing, and authenticating. Missing operations like list/cancel tasks or delete resources are plausible gaps but not critical for typical usage, so the coverage is largely sufficient.