kenari-media-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KENARI_API_KEY | Yes | Your Kenari API key (format: kn-...). Required for everything except list_media_models. | |
| KENARI_BASE_URL | No | Base URL for the Kenari API. Trailing slashes are trimmed. | https://kenari.id/v1 |
| KENARI_OUTPUT_DIR | No | Directory where generated media files are saved (created recursively). Absolute file paths are returned. | ./kenari-output |
| KENARI_ALLOW_VIDEO | No | Set to '0' or 'false' to disable all video tools with a clear error. | allow |
| KENARI_MAX_IMAGE_N | No | Preflight cap for the 'n' parameter in image generation. | 4 |
| KENARI_MAX_VIDEO_DURATION | No | Preflight cap for the 'duration' parameter (seconds) in video generation. | 15 |
| KENARI_MAX_COST_IDR_PER_CALL | No | Optional per-call IDR ceiling for image tools (best-effort catalog lookup). |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_media_modelsA | List Kenari media-capable models (image/video). Public, no key needed. |
| generate_imageA | Generate image(s) via POST /v1/images/generations. Saves PNG/JPG to KENARI_OUTPUT_DIR and returns absolute path(s). Costs IDR per image — check list_media_models first. |
| edit_imageA | Edit a local image via POST /v1/images/edits (multipart: image, mask?, prompt, model, n?, size?, background?). background=transparent is rejected (use generate_image instead). |
| create_videoA | Start a Kenari video job via POST /v1/videos/generations. Returns job id; poll with get_video_status/wait_for_video. Costs money. |
| extend_videoA | Extend a finished video via POST /v1/videos/extensions {model, video:{url}, prompt?, duration?}. source is a job id or https URL — local paths are rejected before any HTTP call. |
| get_video_statusA | GET /v1/videos/{id}. Reports queued/rendering/done/failed/expired. Auto-downloads to KENARI_OUTPUT_DIR when done. |
| wait_for_videoA | Poll GET /v1/videos/{id} every 5s (backoff cap 15s) until done/failed/expired or timeout (default 20 min). Auto-downloads when done. Timeout returns still_rendering with isError=false. |
| download_videoA | Download finished video bytes via GET /v1/videos/{id}/content to KENARI_OUTPUT_DIR. Errors with still_rendering while the job renders. |
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 8 tools
Image generation/edit and video create/extend are clearly separated, and each tool has a distinct action. However, get_video_status, wait_for_video, and download_video overlap somewhat: both status tools auto-download and wait_for_video is essentially status polling with a loop, which can cause agent misselection.
All tool names follow a consistent snake_case verb_noun pattern: generate_image, edit_image, create_video, extend_video, download_video, etc. The naming style is uniform and predictable across image and video workflows.
Eight tools is well-scoped for a media generation server covering both images and videos. Each tool maps to a meaningful API operation or workflow helper without unnecessary redundancy.
The core media lifecycle is covered: list models, generate/edit images, create/extend videos, check status, wait, and download results. Minor gaps exist around video cancellation/deletion and explicit image result management, but agents can complete primary workflows without workarounds.