Nectar is a stdio MCP server for Pollinations image, video, and audio generation. It gives MCP clients a focused set of creative media tools.
You can generate and edit images, create videos, and generate speech, music, or sound effects. Nectar also lists live models and checks pollen balance. It is intentionally not a full Pollinations wrapper. Text generation, transcription, embeddings, and unrelated account tools remain out of scope.
Tool | Purpose |
| Lists current image, video, and audio models from Pollinations using separate 15-minute catalog caches, compact summaries, sorting, and capability filters. |
| Returns full metadata for one image, video, or audio model by name or alias. |
| Generates an image from a text prompt with model, size/dimensions, quality, seed, safety, transparency, prompt enhancement, negative prompt, reference image, and response format options. |
| Edits one or more image URLs using a text prompt, with model, size/dimensions, quality, seed, safety, transparency, prompt enhancement, negative prompt, and response format options. |
| Generates a video from a text prompt, with model, duration, aspect ratio, resolution, seed, audio, safety, quality, and reference-frame controls. |
| Generates speech, music, or sound effects with a selected audio model and optional voice, then saves the returned audio locally by default. |
| Checks the authenticated pollen balance or API key budget. |
Related MCP server: promptpilot-mcp-server
Node.js 20 or newer
A Pollinations API key from enter.pollinations.ai
Model listing does not require authentication. Generation and balance tools require POLLINATIONS_API_KEY.
Generated images, edited images, videos, and audio are saved locally by default. Set NECTAR_OUTPUT_DIR in your MCP client environment block to choose the default output folder. You can also pass output_dir per tool call.
Most MCP clients should pass the API key through the server env block:
{
"mcpServers": {
"pixara": {
"command": "npx",
"args": ["-y", "@pinkpixel/nectar-mcp"],
"env": {
"POLLINATIONS_API_KEY": "sk_your_key_here",
"NECTAR_OUTPUT_DIR": "/absolute/path/to/nectar-output"
}
}
}
}For local development:
git clone https://github.com/pinkpixel-dev/nectar-mcp.git
cd nectar-mcp
npm install
npm run build{
"mcpServers": {
"nectar": {
"command": "node",
"args": ["/absolute/path/to/nectar-mcp/dist/index.js"],
"env": {
"POLLINATIONS_API_KEY": "sk_your_key_here",
"NECTAR_OUTPUT_DIR": "/absolute/path/to/nectar-output"
}
}
}
}Ask your MCP client:
List Pollinations video models and help me choose one for a 9:16 product teaser.Generate a 1024x1024 image of a tiny yellow robot painter in a polished dark UI style.Edit this image URL so the background is transparent and the subject looks more premium.Generate a 6 second 16:9 video of a glowing pollen trail drifting across a dark studio surface.Generate a warm spoken welcome with the nova voice using a current Pollinations speech model.Generate a short lo-fi instrumental with soft piano, brushed drums, and a quiet vinyl texture.Generate the sound of a heavy wooden door closing in a large stone hall.Image generation uses Pollinations' OpenAI-compatible image generation endpoint.
Image editing currently supports image URLs. Local multipart file upload is intentionally left out of v1.
Image, video, and audio tools default to save_output: true, converting base64 responses and downloaded URLs into local files.
Image generation and image editing default to Pollinations response_format: "b64_json" because local decoding is the most reliable save path.
Saved files go to output_dir, NECTAR_OUTPUT_DIR, or ./nectar-output, in that order.
Saved Pollinations media URLs are downloaded with the configured POLLINATIONS_API_KEY. Nectar does not send that key to non-Pollinations URLs.
Tool descriptions intentionally include model examples, parameter guidance, return shape notes, and error-handling hints so MCP clients have enough context to call the tools correctly.
Model listing is compact by default. Audio discovery reads /audio/models, including live voice metadata when Pollinations supplies it.
Use pollinations_get_model_details when an agent needs full raw metadata for one model.
Video generation returns the final media URL and response metadata.
Audio generation uses GET /audio/{text}. The selected model determines whether the prompt produces speech, music, or a sound effect.
Audio saving detects common MP3, WAV, FLAC, Ogg/Opus, AAC, MP4 audio, WebM audio, and PCM media types.
Model support varies by capability, so call pollinations_list_models before using model-specific options.
The server never stores your API key. Your MCP client passes it through the process environment.
npm run typecheck
npm run buildThe server communicates over stdio and will stay running when started directly. Use an MCP client or inspector to interact with it.
Apache-2.0
Made by Pink Pixel.
Check the authenticated Pollinations pollen balance or API key budget by calling /account/balance. Use this before expensive image/video generation when the user asks about available pollen, credits, budget, or why a generation may be failing with payment/balance errors. Requires POLLINATIONS_API_KEY in the MCP client's env block. Args: - response_format (string, optional, default markdown): markdown for readable balance output, json for raw account/budget response. Returns: The remaining pollen balance or API key budget fields returned by Pollinations. Error handling: 401 means the MCP server is missing POLLINATIONS_API_KEY or the key is invalid. 403 means the key lacks account:usage permission. 402 on generation tools means insufficient pollen, so use this tool to confirm the balance.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | MCP response format: markdown for readable balance output, json for raw Pollinations account response. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds critical context beyond that: the requirement for POLLINATIONS_API_KEY in the MCP client's env block, and detailed HTTP error semantics (401/403/402). This equips the agent for real-world deployment and troubleshooting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, usage timing, auth, args, returns, and errors. Every sentence conveys necessary information without fluff or redundancy, making it dense yet easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, read-only, no output schema), the description covers all relevant aspects: what it does, when to use it, required environment setup, what it returns, and error handling. An agent has everything needed to invoke it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes response_format with enum values, default, and a description. The tool description's arg explanation ('markdown for readable balance output, json for raw account/budget response') essentially restates the schema's description without adding new meaning, so it meets the baseline but adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and names the exact resource ('Pollinations pollen balance or API key budget') plus the underlying endpoint ('/account/balance'). This clearly differentiates it from the sibling generation and model-listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this before expensive image/video generation when the user asks about available pollen, credits, budget, or why a generation may be failing with payment/balance errors.' This gives actionable, context-rich guidance that an agent can directly apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit or transform existing image URL(s) with Pollinations using a text instruction. This calls Pollinations' OpenAI-compatible image editing endpoint with JSON image URLs. Use this when the user provides one or more source images and wants changes such as restyling, object/background changes, cleanup, transparent background, composition changes, or image-to-image transformations. Do NOT use this for a brand-new image with no source image; use pollinations_generate_image instead. Args: - prompt (string, required): Editing instruction. Say exactly what to change and what to preserve. Example: 'keep the bee robot unchanged, replace the background with a dark charcoal studio surface, make the wings more translucent'. - image (string or string[], required): Source image URL or URLs. Local file paths are not supported in v1. If the user has a local image, upload it elsewhere first or use a public/content-addressed URL. - model (string, optional): Image-editing-capable Pollinations model. Good candidates may include kontext, gptimage, gptimage-large, gpt-image-2, seedream, seedream-pro, nanobanana, nanobanana-2, nanobanana-pro, klein, p-image-edit. Call pollinations_list_models first if unsure. - n (number, optional, default 1): Number of edited outputs. Pollinations currently supports max 1. - size (string, optional): Output size as WIDTHxHEIGHT, e.g. 1024x1024. If omitted, Pollinations chooses the default. If width and height are provided and size is omitted, Nectar sends WIDTHxHEIGHT as size. - width and height (numbers, optional): Alternative output dimension controls. - quality (string, optional): standard, hd, low, medium, or high. Best supported by gptimage/gpt-image models; unsupported models may ignore it. - response_format (string, optional, default b64_json): b64_json is preferred for local saving because Nectar can decode it directly. Use url only when the caller explicitly wants a Pollinations URL instead of embedded image data. - save_output (boolean, optional, default true): Save returned image data or URL media to a local file and include the path in the result. - output_dir (string, optional): Directory for saved files. Defaults to NECTAR_OUTPUT_DIR or ./nectar-output relative to the server process. - filename_prefix (string, optional): Prefix for saved media filenames. Nectar sanitizes this value. - seed (number, optional): Reproducibility seed where supported. Use -1 for random. - enhance (boolean, optional): Ask Pollinations to enhance the prompt where supported. - negative_prompt (string, optional): Things to avoid in the edited output, where supported. - transparent (boolean, optional): Request transparent output. Best supported by gptimage, gptimage-large, and gpt-image-2. - safe (string, optional): Comma-separated safety filters: privacy, secrets, sexual, violence, shield, true, nsfw. - user (string, optional): End-user identifier for abuse tracking. - output_format (string, optional, default markdown): markdown summary or raw json response. Returns: Markdown or JSON with the edited image URL, base64 length, and revised_prompt when returned. Examples: Use when the user says 'make this image transparent', 'change the outfit', 'turn this logo into a sticker', or 'use this reference image but make it cyberpunk'. Error handling: 401 means missing/invalid POLLINATIONS_API_KEY. 402 means insufficient pollen. 403 means selected model/key permission issue. 400 usually means an unsupported edit model, invalid image URL, or conflicting options; call pollinations_list_models and retry with a model that supports editing.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Number of edited images. Pollinations currently supports 1. | |
| safe | No | Optional comma-separated safety filters: privacy, secrets, sexual, violence, shield, true, nsfw. true enables privacy,secrets. nsfw enables sexual,violence. | |
| seed | No | Optional seed for reproducible edits where supported. Use -1 for random. | |
| size | No | Optional output size as WIDTHxHEIGHT, for example 1024x1024 or 1536x1024. If width and height are set and size is omitted, Nectar sends WIDTHxHEIGHT as size. | |
| user | No | Optional end-user identifier for abuse tracking. | |
| image | Yes | Required source image URL or URLs to edit. Local file paths and multipart uploads are intentionally not supported in v1. | |
| model | No | Optional image-editing model slug. Examples: kontext, gptimage, gptimage-large, gpt-image-2, seedream, seedream-pro, nanobanana, nanobanana-2, nanobanana-pro, klein, p-image-edit. Call pollinations_list_models for current capabilities. | |
| width | No | Optional output width in pixels. Use with height as an alternative to size. | |
| height | No | Optional output height in pixels. Use with width as an alternative to size. | |
| prompt | Yes | Required edit instruction. Be clear about what to change and what must remain unchanged. | |
| enhance | No | Optional prompt enhancement flag. Supported models may expand/improve the edit prompt. | |
| quality | No | Output quality: standard, hd, low, medium, high. Unsupported models may ignore this. | medium |
| output_dir | No | Directory where edited image files should be saved. Defaults to NECTAR_OUTPUT_DIR or ./nectar-output. | |
| save_output | No | Save returned edited image output to a local file. Works for both url and b64_json Pollinations responses. | |
| transparent | No | Optional transparent background/output request. Best supported by gptimage, gptimage-large, and gpt-image-2. | |
| output_format | No | MCP response format: markdown for readable summaries, json for raw Pollinations response plus saved_files metadata when saving is enabled. | markdown |
| filename_prefix | No | Optional prefix for saved edited image filenames. Example: transparent-logo or edited-portrait. | |
| negative_prompt | No | Optional negative prompt describing what to avoid in the edited image, where supported. | |
| response_format | No | Pollinations response format. Defaults to b64_json so Nectar can save edited images locally without a second download. Use url only when the caller explicitly wants a Pollinations URL. | b64_json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only signal readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial behavioral context beyond these: it calls the Pollinations OpenAI-compatible endpoint, saves output to local files by default (save_output=true), explains response formats and revised_prompt, and documents error codes (401/402/403/400). This is rich, non-contradictory behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections (usage, args, returns, examples, error handling). It front-loads the core purpose and usage guidance. A small amount of redundancy with the schema's parameter descriptions exists, but each sentence generally earns its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 19 parameters, no output schema, and a complex external API, the description still manages to cover when to use, how to invoke, parameter details, expected return values, examples, and error handling. The inclusion of a concrete example instruction ('keep the bee robot unchanged, replace the background...') and exact error semantics makes it exceptionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description goes far beyond the schema by adding practical guidance for each parameter: recommended model candidates (kontext, gptimage, etc.), the relationship between size/width/height, preference for b64_json because Nectar can decode it directly, and explicit caveats like 'Local file paths are not supported in v1.' It significantly enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Edit or transform existing image URL(s) with Pollinations using a text instruction.' It explicitly names the underlying endpoint and clearly distinguishes itself from the sibling tool pollinations_generate_image by stating 'Do NOT use this for a brand-new image with no source image; use pollinations_generate_image instead.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Use this when the user provides one or more source images and wants changes such as restyling, object/background changes, cleanup...'), a direct exclusion with an alternative tool, and even advises calling pollinations_list_models first if unsure about the model. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt using Pollinations image models. This calls Pollinations' OpenAI-compatible image generation endpoint and returns either a generated image URL or base64 image data. Use this when the user wants a new image from text, optionally with reference images for image-to-image generation. Do NOT use this for editing an existing image with specific source-image transformation instructions; use pollinations_edit_image instead. Args: - prompt (string, required): Text description of the desired image. Be specific about subject, style, composition, lighting, colors, and any text that should appear. - model (string, optional): Pollinations image model slug. Known image models include kontext, nanobanana, nanobanana-2, nanobanana-2-lite, nanobanana-pro, seedream5, seedream5-pro, seedream, seedream-pro, ideogram-v4-turbo, ideogram-v4-balanced, ideogram-v4-quality, gptimage, gptimage-large, gpt-image-2, flux, zimage, wan-image, wan-image-pro, qwen-image, grok-imagine, grok-imagine-pro, klein, p-image, p-image-edit, nova-canvas. Call pollinations_list_models first for current pricing/capabilities. - n (number, optional, default 1): Number of images. Pollinations currently supports max 1. - size (string, optional): Output size as WIDTHxHEIGHT, e.g. 1024x1024, 1536x1024, 1024x1536. Do not combine with width/height unless intentionally overriding. - width and height (numbers, optional): Alternative dimension controls. If both are provided and size is omitted, Nectar sends size as WIDTHxHEIGHT. - quality (string, optional): standard, hd, low, medium, or high. Best supported by gptimage, gptimage-large, and gpt-image-2; other models may ignore it. - response_format (string, optional, default b64_json): b64_json is preferred for local saving because Nectar can decode it directly. Use url only when the caller explicitly wants a Pollinations URL instead of embedded image data. - save_output (boolean, optional, default true): Save returned image data or URL media to a local file and include the path in the result. - output_dir (string, optional): Directory for saved files. Defaults to NECTAR_OUTPUT_DIR or ./nectar-output relative to the server process. - filename_prefix (string, optional): Prefix for saved media filenames. Nectar sanitizes this value. - image (string or string[], optional): Reference image URL(s) for image-to-image generation on supported models such as kontext, gptimage, seedream, klein, and nanobanana. - seed (number, optional): Reproducibility seed. Use -1 for random. Supported by models such as flux, zimage, seedream, and klein; other models may ignore it. - enhance (boolean, optional): Ask Pollinations to enhance/expand the prompt when supported. - negative_prompt (string, optional): Things to avoid in the generated image when supported. - transparent (boolean, optional): Request a transparent background. Only supported by gptimage, gptimage-large, and gpt-image-2. - safe (string, optional): Comma-separated safety filters: privacy, secrets, sexual, violence, shield, true, nsfw. true means privacy,secrets. nsfw means sexual,violence. - user (string, optional): End-user identifier for abuse tracking. - output_format (string, optional, default markdown): markdown summary or raw json response. Returns: Markdown or JSON with the generated URL, base64 length, and revised_prompt when Pollinations returns one. Examples: Use model=flux, prompt only for a general image. Use model=gpt-image-2 with transparent=true for a transparent asset. Use image=[url] with kontext or nanobanana for image-to-image reference generation. Error handling: 401 means missing/invalid POLLINATIONS_API_KEY in the MCP env block. 402 means insufficient pollen balance. 403 means the key lacks permission for the selected model. 429 means wait and retry. 400 usually means conflicting or unsupported parameters; call pollinations_list_models and retry with model-supported options.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Number of images to generate. Pollinations currently supports 1. | |
| safe | No | Optional comma-separated safety filters: privacy, secrets, sexual, violence, shield, true, nsfw. true enables privacy,secrets. nsfw enables sexual,violence. false or 0 disables safety filters. | |
| seed | No | Optional seed for reproducible results. Use -1 for random. Supported by flux, zimage, seedream, and klein; unsupported models may ignore it. | |
| size | No | Optional image size as WIDTHxHEIGHT, for example 1024x1024, 1536x1024, or 1024x1536. If omitted, Pollinations chooses the default. If width and height are both set and size is omitted, Nectar sends WIDTHxHEIGHT as size. | |
| user | No | Optional end-user identifier for abuse tracking. | |
| image | No | Optional reference image URL or URLs for image-to-image generation on supported models such as kontext, gptimage, seedream, klein, and nanobanana. | |
| model | No | Optional Pollinations image model slug. Examples: flux, kontext, gptimage, gptimage-large, gpt-image-2, seedream5, seedream5-pro, seedream, seedream-pro, nanobanana, nanobanana-2, nanobanana-pro, grok-imagine, wan-image, qwen-image, klein, p-image, p-image-edit, nova-canvas. Call pollinations_list_models first for current models. | |
| width | No | Optional image width in pixels. Use with height as an alternative to size. | |
| height | No | Optional image height in pixels. Use with width as an alternative to size. | |
| prompt | Yes | Required text description of the image. Include subject, composition, style, lighting, colors, mood, and any exact text that should appear. | |
| enhance | No | Optional prompt enhancement flag. When supported, Pollinations may expand/improve the prompt before generation. | |
| quality | No | Image quality: standard, hd, low, medium, high. Best supported by gptimage, gptimage-large, and gpt-image-2; other models may ignore it. | medium |
| output_dir | No | Directory where generated image files should be saved. Defaults to NECTAR_OUTPUT_DIR or ./nectar-output. | |
| save_output | No | Save returned image output to a local file. Works for both url and b64_json Pollinations responses. | |
| transparent | No | Optional transparent background request. Only supported by gptimage, gptimage-large, and gpt-image-2. | |
| output_format | No | MCP response format: markdown for readable summaries, json for raw Pollinations response plus saved_files metadata when saving is enabled. | markdown |
| filename_prefix | No | Optional prefix for saved image filenames. Example: bee-logo or product-shot. | |
| negative_prompt | No | Optional negative prompt describing what to avoid, when the selected model supports negative prompts. | |
| response_format | No | Pollinations image response format. Defaults to b64_json so Nectar can save the image locally without a second download. Use url only when the caller explicitly wants a Pollinations URL. | b64_json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), the description discloses rich behavioral context: whether output is a URL or base64, local saving behavior with save_output, default output directory, model-specific support for features like transparent and negative_prompt, and a detailed error-handling section covering 400/401/402/403/429 responses. This far exceeds what annotations provide and contains no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place given the tool's complexity. It is front-loaded with the core purpose, then moves through behavior, parameters, return format, examples, and error handling in a logical, scannable structure. No filler sentences; each part provides actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly covers return values ('Returns: Markdown or JSON with the generated URL, base64 length, and revised_prompt'). It also includes examples for common scenarios, error handling, and parameter interplay. For a tool of this complexity (19 params, multiple modes, network calls), the description is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds substantial meaning beyond the raw schema. It explains prompt specificity, the complete list of known model slugs, the rationale for choosing b64_json over url, how width/height interact with size, what Nectar sanitizes, what safe filter values mean, and which parameters are model-dependent. This is exemplary parameter guidance for a 19-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Generate an image from a text prompt using Pollinations image models') and clearly distinguishes from the sibling tool by stating 'Do NOT use this for editing an existing image... use pollinations_edit_image instead.' It also covers both text-to-image and image-to-image modes, leaving no ambiguity about its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when the user wants a new image from text, optionally with reference images for image-to-image generation.' It gives exclusions and alternatives: 'Do NOT use this for editing an existing image with specific source-image transformation instructions; use pollinations_edit_image instead.' It also advises calling pollinations_list_models first for current capabilities, and gives practical examples for common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a video from a text prompt using Pollinations video models. This calls GET /video/{prompt} and returns the final media URL plus response metadata. Use this when the user wants text-to-video or image-to-video output. For static images, use pollinations_generate_image instead. Args: - prompt (string, required): Text description of the video. Include subject, scene, motion, camera movement, mood, lighting, style, and any timing notes. - model (string, required): Pollinations video model slug. Known video models include veo, seedance-pro, seedance-2.0, wan, wan-fast, wan-pro, wan-pro-1080p, grok-video-pro, ltx-2, p-video-720p, p-video-1080p, nova-reel. Call pollinations_list_models with modality=video first for current capabilities/pricing. - duration (number, optional, 1-120): Duration in seconds. Model rules vary: veo supports 4, 6, or 8s; seedance supports 2-10s; seedance-2.0 supports 4-15s; wan supports 2-15s; nova-reel supports 6-120s in multiples of 6. - aspectRatio (string, optional): 16:9 or 9:16. Use 16:9 for landscape, 9:16 for vertical/social video. If omitted, Pollinations may derive it from width/height. - width and height (numbers, optional): Requested dimensions. Video models map these to nearest supported resolution tiers such as 480p, 720p, or 1080p. - image (string or string[], optional): Reference frame URL(s). For video, image[0] is the start frame. image[1] is the end frame for models with end_frame support. End frame is documented for veo, seedance, seedance-2.0, and wan-fast; other models may ignore image[1]. - audio (boolean, optional): Request generated audio where supported. For veo, set true to enable audio. wan may generate audio regardless of this flag. - seed (number, optional): Reproducibility seed. Use -1 for random. Supported by seedance and nova-reel; unsupported models may ignore it. - quality (string, optional): low, medium, high, or hd. Unsupported models may ignore it. - safe (string, optional): Comma-separated safety filters: privacy, secrets, sexual, violence, shield, true, nsfw. - save_output (boolean, optional, default true): Download and save the returned video URL to a local file and include the path in the result. - output_dir (string, optional): Directory for saved files. Defaults to NECTAR_OUTPUT_DIR or ./nectar-output relative to the server process. - filename_prefix (string, optional): Prefix for saved video filenames. Nectar sanitizes this value. - response_format (string, optional, default markdown): markdown summary or json metadata. Returns: Markdown or JSON containing the video URL, content type, and content length when available. Examples: Use model=veo duration=8 aspectRatio=16:9 for a polished landscape clip. Use image=[startUrl,endUrl] with seedance-2.0 or wan-fast for first/last-frame interpolation. Use aspectRatio=9:16 for TikTok/Reels style output. Error handling: 401 means missing/invalid POLLINATIONS_API_KEY. 402 means insufficient pollen. 403 means key/model permission issue. 429 means wait and retry. 400 often means invalid duration/aspect/model combination; call pollinations_list_models and retry with supported values.
| Name | Required | Description | Default |
|---|---|---|---|
| safe | No | Optional comma-separated safety filters: privacy, secrets, sexual, violence, shield, true, nsfw. true enables privacy,secrets. nsfw enables sexual,violence. | |
| seed | No | Optional seed. Use -1 for random. Supported by seedance and nova-reel according to current docs; unsupported models may ignore it. | |
| audio | No | Whether to request generated audio when the model supports it. For veo, true enables audio. wan may generate audio regardless. | |
| image | No | Optional reference image URL or up to two URLs. image[0] is the start frame. image[1] is the end frame for models that support end_frame, documented for veo, seedance, seedance-2.0, and wan-fast. | |
| model | Yes | Required Pollinations video model slug. Examples: veo, seedance-pro, seedance-2.0, wan, wan-fast, wan-pro, wan-pro-1080p, grok-video-pro, ltx-2, p-video-720p, p-video-1080p, nova-reel. Call pollinations_list_models with modality=video if unsure. | |
| width | No | Optional requested width in pixels. Video models map this to the nearest supported tier such as 480p, 720p, or 1080p. | |
| height | No | Optional requested height in pixels. Video models map this to the nearest supported tier such as 480p, 720p, or 1080p. | |
| prompt | Yes | Required text description of the video. Include scene, subject, motion, camera movement, style, lighting, and timing notes. | |
| quality | No | Optional quality level. Unsupported models may ignore it. | |
| duration | No | Video duration in seconds. Model support varies: veo 4/6/8; seedance 2-10; seedance-2.0 4-15; wan 2-15; nova-reel 6-120 in multiples of 6. | |
| output_dir | No | Directory where generated video files should be saved. Defaults to NECTAR_OUTPUT_DIR or ./nectar-output. | |
| aspectRatio | No | Optional video aspect ratio. Use 16:9 for landscape and 9:16 for vertical/social video. If omitted, Pollinations may derive it from width and height. | |
| save_output | No | Download and save the generated video URL to a local file. | |
| filename_prefix | No | Optional prefix for saved video filenames. Example: product-teaser or intro-clip. | |
| response_format | No | MCP response format: markdown for readable summaries, json for returned URL/content metadata plus saved_files metadata when saving is enabled. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behavior beyond annotations: error handling (401/402/403/429/400), model-specific parameter support (e.g., veo durations, seed support), audio behavior for veo/wan, aspect ratio derivation, resolution mapping, end-frame handling, and save_output side effects. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite its length, the description is well-structured and information-dense. It front-loads core functionality, then systematically covers parameters, return values, examples, and error handling. Every sentence adds unique value, particularly model compatibility details that are not in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 15 parameters and no output schema, the description is exceptionally complete. It explains return values (Markdown/JSON with URL and metadata), error semantics, parameter constraints, and usage patterns. It fully equips an agent to invoke the tool correctly without needing external lookups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema: model-specific duration rules, supported models for seed, end-frame semantics, quality tiers, and practical examples (veo duration=8, aspectRatio=9:16 for TikTok). It clarifies parameter interactions and defaults like save_output and response_format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Generate a video from a text prompt using Pollinations video models' and references the specific endpoint GET /video/{prompt}. It also differentiates from the sibling tool by saying 'For static images, use pollinations_generate_image instead.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this when the user wants text-to-video or image-to-video output.' It gives an alternative tool for static images and even recommends calling pollinations_list_models first for current capabilities, providing both when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full metadata for one Pollinations image or video model by name or alias. Use this after pollinations_list_models when an agent needs exact pricing, capabilities, reference-image limits, input/output modalities, aliases, or raw fields for a specific model. Results use the same 15-minute in-memory model catalog cache unless refresh=true. Args: - model (string, required): Model name or alias, e.g. nanobanana, p-image-edit, ltx-2, wan-fast, veo. - refresh (boolean, optional, default false): Bypass the 15-minute cache and refetch /image/models first. - response_format (string, optional, default markdown): markdown for readable details, json for raw model metadata. Returns: Full metadata for the matching model. If no model matches, call pollinations_list_models with a broader search.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name or alias to inspect, for example nanobanana, p-image-edit, ltx-2, wan-fast, or veo. | |
| refresh | No | Bypass the 15-minute in-memory cache and refetch the Pollinations model catalog. | |
| response_format | No | MCP response format: markdown for readable model details, json for raw metadata. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, this description reveals important behavioral traits: the 15-minute in-memory cache behavior, the ability to bypass it with refresh=true, and that refresh refetches /image/models first. It also states the return value is full metadata, which adds transparency about what the agent will receive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: it opens with the core purpose, follows with usage context, then a structured args list, and closes with returns and fallback behavior. Every sentence carries necessary information, and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup tool, this description is complete. It covers purpose, usage timing, cache/refresh behavior, response format options, return value, and a failure fallback action. The lack of an output schema is acceptable because the description clarifies that full metadata is returned and gives examples of the fields involved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by giving concrete model examples (nanobanana, p-image-edit, ltx-2) and specifying that refresh refetches /image/models, which is a detail not present in the schema. This modestly elevates it above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves full metadata for a single Pollinations image or video model by name or alias, using the specific verb 'Get' and a specific resource. It differentiates itself from siblings by mentioning it is used after pollinations_list_models for detailed information, and it lists exact fields like pricing and capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this after pollinations_list_models when an agent needs exact pricing, capabilities...' It also provides a fallback instruction: 'If no model matches, call pollinations_list_models with a broader search.' This clearly indicates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently available Pollinations image and video models from /image/models. Results are cached in memory for 15 minutes, so repeated calls are fast. Use this before generation when model choice, pricing, modality, reference-image support, end-frame support, or audio support is unclear. This tool does not require POLLINATIONS_API_KEY. Args: - modality (string, optional, default all): all, image, or video. Use image before image generation/editing. Use video before video generation. - search (string, optional): Case-insensitive search across model names, aliases, brands, descriptions, pricing, capabilities, and raw metadata. Examples: 'gpt', 'transparent', 'end_frame', 'audio', 'seedance', 'banana', 'edit'. Do not use search='cheap' to find cheapest; inspect the Pricing lines instead. - limit (number, optional, default 50, max 100): Maximum number of models to return. - detail (string, optional, default summary): summary returns compact model cards; full returns richer metadata for listed models. For one model, prefer pollinations_get_model_details. - sort_by (string, optional, default default): default, name, or price. Use sort_by=price and sort_order=asc to find cheaper models. - sort_order (string, optional, default asc): asc or desc. - paid_only (boolean, optional): Filter by paid_only flag. - supports_reference_images (boolean, optional): true returns models with max_reference_images > 0. - supports_end_frame (boolean, optional): true returns video models with end_frame capability. - supports_audio (boolean, optional): true returns models that output audio or support audio_output. - refresh (boolean, optional, default false): Bypass the 15-minute in-memory cache and refetch /image/models. - response_format (string, optional, default markdown): markdown for readable summaries, json for structured compact/full metadata. Returns: Compact model names, category, pricing, input/output modalities, and key capability flags by default. Use pollinations_get_model_details for complete raw metadata for one model. Examples: Cheapest images: modality=image, sort_by=price, sort_order=asc, limit=5. Cheapest videos: modality=video, sort_by=price, sort_order=asc, limit=5. First/last-frame videos: modality=video, supports_end_frame=true. Image editing/reference models: modality=image, supports_reference_images=true. Error handling: If no models match, retry with modality=all, remove search, or remove capability filters. Use refresh=true only when you need current model changes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of models to return. | |
| detail | No | summary returns compact low-context model cards. full returns richer metadata for listed models. Use pollinations_get_model_details for one model's full raw metadata. | summary |
| search | No | Optional case-insensitive search across names, aliases, brands, descriptions, capabilities, pricing, and metadata. Examples: gpt, transparent, end_frame, audio, edit, seedance, banana. Do not use cheap as a search term; inspect Pricing instead. | |
| refresh | No | Bypass the 15-minute in-memory cache and refetch the Pollinations model catalog. | |
| sort_by | No | Sort models by default API order, name, or lowest numeric pricing value. | default |
| modality | No | Filter models by modality: all, image, or video. Use video before video generation and image before image generation/editing. | all |
| paid_only | No | Optional paid_only filter. true returns paid-only models; false returns models not marked paid-only. | |
| sort_order | No | Sort direction for name or price sorting. | asc |
| supports_audio | No | Optional filter for models that output audio or support video audio_output. | |
| response_format | No | MCP response format: markdown for readable summaries, json for raw model metadata. | markdown |
| supports_end_frame | No | Optional filter for video models with end_frame capability. | |
| supports_reference_images | No | Optional filter for models with max_reference_images greater than zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description discloses 15-minute in-memory caching, no API key requirement, refresh behavior, and error handling guidance. This adds meaningful operational context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but organized into Args, Returns, Examples, and Error handling, with a clear first sentence. Minor redundancy exists (e.g., the 'prefer pollinations_get_model_details' advice appears twice), so it is not perfect, but it earns its detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return content ('Compact model names, category, pricing, input/output modalities, and key capability flags'), provides worked examples for common queries, and covers error handling. For a 12-parameter list tool with caching and various filters, this is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers all 12 parameters, the description enriches them with practical guidance: e.g., 'Use sort_by=price and sort_order=asc to find cheaper models,' and warns against using 'cheap' as a search term. It also maps filters to use cases like reference-image support and end-frame videos.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List currently available Pollinations image and video models from /image/models.' This clearly distinguishes it from sibling tools like pollinations_generate_image or pollinations_get_model_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'Use this before generation when model choice, pricing, modality, reference-image support, end-frame support, or audio support is unclear.' It also provides exclusions ('Do not use search='cheap'') and points to alternatives ('For one model, prefer pollinations_get_model_details').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0pollinations_check_balancepollinations_edit_imagepollinations_generate_imagepollinations_generate_videopollinations_get_model_detailspollinations_list_modelsEach tool has a clearly distinct purpose: generate new images vs edit existing ones vs generate videos vs list/fetch model metadata vs check account balance. The descriptions explicitly cross-reference when to use each, eliminating ambiguity.
All tools follow a consistent pollinations_<verb>_<noun> pattern with snake_case: generate_image, edit_image, generate_video, list_models, get_model_details, check_balance. No mixing of conventions or vague verbs.
Six tools is well-scoped for a media generation API, covering the core actions (image gen/edit, video gen) plus necessary supporting utilities (model discovery and account balance). No bloat or unnecessary duplication.
The surface covers all primary workflows: image generation, image editing, video generation (including image-to-video via reference frames), model discovery and details, and balance checking. There are no obvious dead ends or missing critical operations for the stated purpose.
Multi-model AI image and video generator. 14 models behind one OAuth-secured MCP endpoint.
Create and edit images, videos, and audio through Magic Hour's hosted Streamable HTTP MCP server.
AI image, video, voice and music generation over MCP, routed to Veo 3.1, Seedance 2.0 and more.
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pinkpixel-dev/nectar-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
