Skip to main content
Glama
enesjakozh
pinkpixel-dev

MCPollinations Multimodal MCP Server

by pinkpixel-dev
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

This server is archived as it no longer works with Pollinations newer API. Please see Nectar-MCP for my new Pollinations MCP server, specifically for image generation, image editing, and video generation.

MCPollinations Multimodal MCP Server

A Model Context Protocol (MCP) server that enables AI assistants to generate images, text, and audio through the Pollinations APIs

Features

  • Generate image URLs from text prompts

  • Generate images and return them as base64-encoded data AND save as png, jpeg, jpg, or webp (default: png)

  • Generate text responses from text prompts

  • Generate audio responses from text prompts

  • List available image and text generation models

  • No authentication required

  • Simple and lightweight

  • Compatible with the Model Context Protocol (MCP)

Related MCP server: GPT Image 1 MCP

System Requirements

  • Node.js: Version 14.0.0 or higher

    • For best performance, we recommend Node.js 16.0.0 or higher

    • Node.js versions below 16 use an AbortController polyfill

Quick Start

Installing via Smithery

To install mcpollinations for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @pinkpixel-dev/mcpollinations --client claude

The easiest way to use the MCP server:

# Run directly with npx (no installation required)
npx @pinkpixel/mcpollinations

If you prefer to install it globally:

# Install globally
npm install -g @pinkpixel/mcpollinations

# Run the server
mcpollinations
# or
npx @pinkpixel/mcpollinations

Or clone the repository:

# Clone the git repository
git clone https://github.com/pinkpixel-dev/mcpollinations.git
# Run the server
mcpollinations
# or
npx @pinkpixel/mcpollinations
# or run directly
node /path/to/MCPollinations/pollinations-mcp-server.js

MCP Integration

To integrate the server with applications that support the Model Context Protocol (MCP):

  1. Generate an MCP configuration file:

# If installed globally
npx @pinkpixel/mcpollinations generate-config

# Or run directly
node /path/to/MCPollinations/generate-mcp-config.js

Quick MCP Config (env)

If you prefer to skip the generator, copy this into your MCP client config:

{
  "mcpollinations": {
    "command": "npx",
    "args": ["-y", "@pinkpixel/mcpollinations"],
    "env": {
      "token": "YOUR_TOKEN_OPTIONAL",
      "referrer": "your-app-or-domain-optional",
      "IMAGE_MODEL": "flux",
      "IMAGE_WIDTH": "1024",
      "IMAGE_HEIGHT": "1024",
      "IMAGE_ENHANCE": "true",
      "IMAGE_SAFE": "false",
      "TEXT_MODEL": "openai",
      "TEXT_TEMPERATURE": "0.7",
      "TEXT_TOP_P": "0.9",
      "TEXT_SYSTEM": "",
      "AUDIO_VOICE": "alloy",
      "OUTPUT_DIR": "./mcpollinations-output"
    }
  }
}

  1. Follow the prompts to customize your configuration or use the defaults.

    • Set an output directory (relative paths recommended for portability)

      • Windows users: Consider using absolute paths (e.g., C:\Users\YourName\Pictures\MCPollinations) for more reliable file saving

    • Configure optional authentication (token, referrer) under env

    • Configure default parameters for image generation (with a list of available models, dimensions, etc.)

    • Configure default parameters for text generation (with a list of available models)

    • Configure default parameters for audio generation (voice)

  2. Copy the generated mcp.json file to your application's MCP settings .json file.

  3. Restart your application.

After integration, you can use commands like:

"Generate an image of a sunset over the ocean using MCPollinations"

Authentication (Optional)

MCPollinations supports optional authentication to provide access to more models and better rate limits. The server works perfectly without authentication (free tier), but users with API tokens can get enhanced access.

Configuration Methods

Method 1: Environment Variables (Recommended for security)

# Set environment variables before running the server
export POLLINATIONS_TOKEN="your-api-token"
export POLLINATIONS_REFERRER="https://your-domain.com"

# Then run the server
npx @pinkpixel/mcpollinations

Method 2: MCP Configuration File (env) When generating your MCP configuration, place auth inside env so your MCP client passes them as environment variables to the server process:

{
  "mcpollinations": {
    "command": "npx",
    "args": ["-y", "@pinkpixel/mcpollinations"],
    "env": {
      "token": "your-api-token",
      "referrer": "your-app-or-domain"
    }
  }
}

You can also provide POLLINATIONS_TOKEN and POLLINATIONS_REFERRER instead; the server recognizes both forms. Using token and referrer inside env is recommended for MCP configs.

Authentication Parameters

  • token (optional): Your Pollinations API token for enhanced access

  • referrer (optional): Your domain/application referrer URL

Both parameters are completely optional. Leave them empty or unset to use the free tier.

Using Your Configuration Settings

MCPollinations respects your MCP configuration settings placed in env as defaults. When you ask an AI assistant to generate content:

  • Your configured models, output directories, and parameters are used automatically

  • To override: Specifically instruct the AI to use different settings

    • "Generate an image using the kontext model"

    • "Save this image to my Desktop folder"

    • "Use a temperature of 1.2 for this text generation"

Example Instructions:

  • ✅ "Generate a sunset image" → Uses your configured model and output directory

  • ✅ "Generate a sunset image with the flux model" → Overrides model only

  • ✅ "Generate a sunset image and save it to C:\Pictures" → Overrides output path only

This ensures your preferences are always respected unless you specifically want different settings for a particular request.

Troubleshooting

"AbortController is not defined" Error

If you encounter this error when running the MCP server:

ReferenceError: AbortController is not defined

This is usually caused by running on an older version of Node.js (below version 16.0.0). Try one of these solutions:

  1. Update Node.js (recommended):

    • Update to Node.js 16.0.0 or newer

  2. Use Global Installation

    • Update to the latest version of the package:

    npm install -g @pinkpixel/mcpollinations
# Run with npx
npx @pinkpixel/mcpollinations

  3. Install AbortController manually:

    • If for some reason the polyfill doesn't work:

    npm install node-abort-controller

Check Your Node.js Version

To check your current Node.js version:

node --version

If it shows a version lower than 16.0.0, consider upgrading for best compatibility.

Available Tools

The MCP server provides the following tools:

Image Generation Tools

  1. generateImageUrl - Generates an image URL from a text prompt

  2. generateImage - Generates an image, returns it as base64-encoded data, and saves it to a file by default (PNG format)

  3. editImage - NEW! Edit or modify existing images based on text prompts

  4. generateImageFromReference - NEW! Generate new images using existing images as reference

  5. listImageModels - Lists available models for image generation

Text & Audio Tools

  1. respondText - Responds with text to a prompt using text models (customizable parameters)

  2. respondAudio - Generates an audio response to a text prompt (customizable voice parameter)

  3. listTextModels - Lists available models for text generation

  4. listAudioVoices - Lists all available voices for audio generation

Text Generation Details

Available Parameters

The respondText tool supports several parameters for fine-tuning text generation:

  • model: Choose from available text models (use listTextModels to see current options)

  • temperature (0.0-2.0): Controls randomness in the output

    • Lower values (0.1-0.7) = more focused and deterministic

    • Higher values (0.8-2.0) = more creative and random

  • top_p (0.0-1.0): Controls diversity via nucleus sampling

    • Lower values = more focused on likely tokens

    • Higher values = considers more token possibilities

  • system: System prompt to guide the model's behavior and personality

Customizing Text Generation

// Example options for respondText
const options = {
  model: "openai",           // Model selection
  temperature: 0.7,          // Balanced creativity
  top_p: 0.9,               // High diversity
  system: "You are a helpful assistant that explains things clearly and concisely."
};

Configuration Examples

In your MCP configuration, set defaults under env so the server uses them automatically:

{
  "mcpollinations": {
    "env": {
      "TEXT_MODEL": "openai",
      "TEXT_TEMPERATURE": "0.7",
      "TEXT_TOP_P": "0.9",
      "TEXT_SYSTEM": "You are a helpful coding assistant."
    }
  }
}

Image-to-Image Generation (NEW!)

MCPollinations now supports powerful image-to-image generation with two specialized tools:

editImage Tool

Perfect for modifying existing images:

  • Remove objects: "remove the cat from this image"

  • Add elements: "add a dog to this scene"

  • Change backgrounds: "replace the background with mountains"

  • Style modifications: "make the lighting more dramatic"

generateImageFromReference Tool

Perfect for creating variations and new styles:

  • Style transfer: "make this photo look like a painting"

  • Format changes: "convert this to a cartoon style"

  • Creative variations: "create a futuristic version of this"

  • Artistic interpretations: "make this look like a sketch"

Supported Models

  • kontext: Specialized model optimized for image-to-image tasks

  • nanobanana: New Google model supporting both text-to-image and image-to-image generation

  • seedream: New ByteDance model supporting both text-to-image and image-to-image generation

Multi-reference images: editImage and generateImageFromReference accept imageUrl as a single URL or an array of URLs. The server encodes arrays as the comma-separated image parameter used by the API. Ordering matters; kontext uses only the first image, nanobanana is safe up to ~4 refs, and seedream supports up to 10.

Important: URLs only. The image-to-image tools require publicly accessible HTTP(S) URLs. Local file paths, file uploads, and base64/data URLs are not supported by this MCP server (it does not upload files). If you need to work from a local image, host it somewhere accessible (e.g., a temporary file host, object storage, or a raw link in a repo) and pass the URL.

Example Usage

// Edit an existing image
const editResult = await editImage(
  "change the background to a sunset beach",
  "https://example.com/photo.jpg",
  "nanobanana"  // or "kontext", "seedream"
);

// Generate from reference
const referenceResult = await generateImageFromReference(
  "make this into a watercolor painting",
  "https://example.com/photo.jpg",
  "seedream"  // or "kontext", "nanobanana"
);

Image Generation Details

Default Behavior

When using the generateImage tool:

  • Images are saved to disk by default as PNG files

  • The default save location is the current working directory where the MCP server is running

  • The 'flux' model is used by default

  • A random seed is generated by default for each image (ensuring variety)

  • Base64-encoded image data is always returned, regardless of whether the image is saved to a file

Customizing Image Generation

// Example options for generateImage
const options = {
  // Model selection (defaults to 'flux')
  // Available models: "flux", "turbo", "kontext", "nanobanana", "seedream"
  model: "flux",

  // Image dimensions
  width: 1024,
  height: 1024,

  // Generation options
  seed: 12345,  // Specific seed for reproducibility (defaults to random)
  enhance: true,  // Enhance the prompt using an LLM before generating (defaults to true)
  safe: false,  // Content filtering (defaults to false)

  // File saving options
  saveToFile: true,  // Set to false to skip saving to disk
  outputPath: "/path/to/save/directory",  // Custom save location
  fileName: "my_custom_name",  // Without extension
  format: "png"  // png, jpeg, jpg, or webp
};

Where Images Are Saved

When using Claude or another application with the MCP server:

  1. Images are saved in the current working directory of where the MCP server is running, not where Claude or the client application is installed.

  2. If you start the MCP server manually from a specific directory, images will be saved there by default.

  3. If Claude Desktop launches the MCP server automatically, images will be saved in Claude Desktop's working directory (typically in an application data folder).

💡 Windows Users: For reliable file saving on Windows, use absolute paths in your MCP configuration instead of relative paths (e.g., C:\Users\YourName\Pictures\MCPollinations instead of ./mcpollinations-output). Relative paths may not resolve as expected depending on the working directory context.

Finding Your Generated Images

  • The response from Claude after generating an image includes the full file path where the image was saved

  • You can specify a familiar location using the outputPath parameter

  • Best practice: Ask Claude to save images to an easily accessible folder like your Pictures or Downloads directory

Unique Filenames

The MCP server ensures that generated images always have unique filenames and will never overwrite existing files:

  1. Default filenames include:

    • A sanitized version of the prompt (first 20 characters)

    • A timestamp

    • A random suffix

  2. Custom filenames are also protected:

    • If you specify a filename and a file with that name already exists, a numeric suffix will be added automatically

    • For example: sunset.png, sunset_1.png, sunset_2.png, etc.

This means you can safely generate multiple images with the same prompt or filename without worrying about overwriting previous images.

Accessing Base64 Data

Even when saving to a file, the base64-encoded image data is always returned and can be used for:

  • Embedding in web pages (<img src="data:image/png;base64,..." />)

  • Passing to other services or APIs

  • Processing in memory without filesystem operations

  • Displaying in applications that support data URIs

For Developers

If you want to use the package in your own projects:

# Install as a dependency
npm install @pinkpixel/mcpollinations

# Import in your code
import { generateImageUrl, generateImage, repsondText, respondAudio, listTextModels, listImageModels, listAudioVoices } from '@pinkpixel/mcpollinations';

Available Tools

9 tools
editImageB

Edit or modify an existing image based on a text prompt. User-configured settings in MCP config will be used as defaults unless specifically overridden.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe text description of how to edit the image (e.g., "remove the cat and add a dog", "change background to mountains")
imageUrlYesPublic HTTP(S) URL(s) of the input image(s) to edit. Accepts a string or an array for multiple references (first is most important). Local file paths, file uploads, or base64/data URLs are not supported.
modelNoModel name to use for editing (default: user config or "kontext"). Available: "kontext", "nanobanana", "seedream"
seedNoSeed for reproducible results (default: random)
widthNoWidth of the generated image (default: 1024)
heightNoHeight of the generated image (default: 1024)
enhanceNoWhether to enhance the prompt using an LLM before generating (default: true)
safeNoWhether to apply content filtering (default: false)
outputPathNoDirectory path where to save the image (default: user config or "./mcpollinations-output")
fileNameNoName of the file to save (without extension, default: generated from prompt)
formatNoImage format to save as (png, jpeg, jpg, webp - default: png)

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It does not mention whether editing is non-destructive, required permissions, or side effects like overwriting files.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The first sentence defines purpose, the second adds context about defaults.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having 11 parameters and no output schema, the description does not explain what the tool returns (e.g., URL, file path, success message). Only mentions saving to outputPath.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds no additional meaning beyond what is already in the input schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool edits/modifies an existing image using a text prompt, distinguishing it from generation tools like generateImage that create new images.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions user-configured defaults can be overridden, but provides no explicit guidance on when to use this tool versus siblings (e.g., generateImage) or any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generateImageA

Generate an image, return the base64-encoded data, and save to a file by default. User-configured settings in MCP config will be used as defaults unless specifically overridden.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe text description of the image to generate
modelNoModel name to use for generation (default: user config or "flux"). Use listImageModels to see all available models
seedNoSeed for reproducible results (default: random)
widthNoWidth of the generated image (default: 1024)
heightNoHeight of the generated image (default: 1024)
enhanceNoWhether to enhance the prompt using an LLM before generating (default: true)
safeNoWhether to apply content filtering (default: false)
outputPathNoDirectory path where to save the image (default: "./mcpollinations-output")
fileNameNoName of the file to save (without extension, default: generated from prompt)
formatNoImage format to save as (png, jpeg, jpg, webp - default: png)

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It states the return of base64 data and file saving, but omits side effects, error handling, permission needs, or whether existing files are overwritten. The default behavior is mentioned but not the underlying service.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundancy. The first sentence succinctly describes the core action and outputs. The second sentence adds important default behavior information. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, no output schema), the description covers the high-level output (base64, file save) and default handling. However, it does not explain the format of base64, file overwrite behavior, or the external service involved. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter has a description. The description adds value by clarifying that user-configured settings in MCP config serve as defaults, which is not in the schema. This provides meaningful context beyond the parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Generate an image' and specifies the outputs: base64-encoded data and saving to a file. It distinguishes from sibling tools like generateImageUrl (URL return) and editImage (edit action).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that user-configured settings are used as defaults, which implies context, but does not explicitly state when to use this tool versus generateImageUrl or editImage. No guidance on exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generateImageFromReferenceB

Generate a new image using an existing image as reference. User-configured settings in MCP config will be used as defaults unless specifically overridden.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe text description of what to generate based on the reference image (e.g., "create a cartoon version", "make it look like a painting")
imageUrlYesPublic HTTP(S) URL(s) of reference images. Accepts a string or an array for multi-reference. Local file paths, file uploads, or base64/data URLs are not supported.
modelNoModel name to use for generation (default: user config or "kontext"). Available: "kontext", "nanobanana", "seedream"
seedNoSeed for reproducible results (default: random)
widthNoWidth of the generated image (default: 1024)
heightNoHeight of the generated image (default: 1024)
enhanceNoWhether to enhance the prompt using an LLM before generating (default: true)
safeNoWhether to apply content filtering (default: false)
outputPathNoDirectory path where to save the image (default: user config or "./mcpollinations-output")
fileNameNoName of the file to save (without extension, default: generated from prompt)
formatNoImage format to save as (png, jpeg, jpg, webp - default: png)

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions user-configured defaults but omits critical details like whether the operation is destructive (overwrites files), auth requirements, rate limits, or output format. The description does not contradict annotations (none exist).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the core purpose. It efficiently conveys the key action. However, it could be more structured (e.g., listing key behaviors).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 11 parameters, no output schema, and no annotations, the description is too brief. It fails to explain the output (e.g., saved file, returned URL), how the reference image is used, or what happens with multiple references. Missing behavioral and result context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds minimal context about defaults from user config, but the schema already documents default values. The description does not clarify interplay between parameters or edge cases.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it generates a new image using an existing image as reference, which is a specific verb+resource. This distinguishes it from siblings like generateImage (no reference) and editImage (modify existing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description does not mention when-not-to-use or suggest sibling tools for different scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generateImageUrlB

Generate an image URL from a text prompt. User-configured settings in MCP config will be used as defaults unless specifically overridden.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe text description of the image to generate
modelNoModel name to use for generation (default: user config or "flux"). Use listImageModels to see all available models
seedNoSeed for reproducible results (default: random)
widthNoWidth of the generated image (default: 1024)
heightNoHeight of the generated image (default: 1024)
enhanceNoWhether to enhance the prompt using an LLM before generating (default: true)
safeNoWhether to apply content filtering (default: false)

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states it generates an image URL but does not disclose behavioral traits such as whether it modifies state, requires authentication, has rate limits, or what errors might occur. The description is too brief to convey important behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at two sentences, with no superfluous words. It front-loads the core action and quickly adds a note about configuration. No wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description should provide more context about the tool's behavior, such as how the URL is returned, expected latency, error handling, or state changes. It feels incomplete for a generative tool with 7 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the baseline is 3. The description adds that user-configured settings can be overridden per parameter, but this is a general note rather than adding specific meaning to parameters beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action and resource: 'Generate an image URL from a text prompt.' It provides a specific verb and resource, making the tool's purpose clear. However, it does not explicitly distinguish this from sibling tools like `generateImage` or `generateImageFromReference`, though the name hints at the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that user-configured settings in MCP config will be used as defaults, giving some context on configuration. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., `generateImage` or `editImage`), nor does it specify when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

listAudioVoicesA

List all available audio voices for text-to-speech generation

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It implies a read-only operation but does not mention side effects, permissions, rate limits, or return format. For a simple list tool, this is adequate but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the core purpose without any fluff. It is appropriately concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description is mostly complete. However, it could briefly mention the expected return type or that the list includes all voices, which would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema coverage is 100%. The description adds no parameter details, but the baseline for 0 parameters is 4, and no additional explanation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (List), resource (audio voices), and context (for text-to-speech generation). It effectively distinguishes from sibling tools, which are mostly image-related, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusion cases, or comparisons with other list tools on the same server.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

listImageModelsA

List available image models

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only nature, data freshness). However, for a simple list tool, the minimal description is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise at only two words. While no extra detail is included, it effectively conveys the tool's purpose without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of parameters and output schema, the description sufficiently explains the tool's functionality. It could mention the output format, but it's complete enough for the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; schema coverage is 100%. The description does not need to add parameter info, so it scores at the baseline of 4 for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List available image models' clearly states the action (list) and resource (available image models), distinguishing it from sibling tools like generateImage or editImage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, such as mentioning it should be used to discover model options before generating images.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

listTextModelsB

List available text models

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only says 'List available text models' without disclosing whether the operation is read-only, requires authentication, or has any behavioral constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (5 words) and to the point. It could be slightly more informative, but it is appropriately sized for a simple list operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple parameterless tool, but it lacks any mention of the return value format or behavior. Given the absence of an output schema and annotations, more context would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% schema description coverage. According to the guidelines, 0 parameters yields a baseline of 4. The description does not need to add parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'available text models'. It distinguishes from sibling tools 'listAudioVoices' and 'listImageModels' by specifying the 'text' modality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The sibling tool names imply different modalities, but the description does not state when to use this tool or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

respondAudioB

Generate an audio response to a text prompt and play it through the system

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe text prompt to respond to with audio
voiceNoVoice to use for audio generation (default: "alloy"). Available options: "alloy", "echo", "fable", "onyx", "nova", "shimmer", "coral", "verse", "ballad", "ash", "sage", "amuch", "dan"
seedNoSeed for reproducible results (default: random)

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions playing audio, but does not disclose potential side effects, system requirements, or resource implications. For a generative tool, more behavioral context is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is both concise and front-loaded with the key action 'Generate'. No unnecessary details, achieving maximum conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (audio generation and playback), the description is too sparse. It omits information about return values, output format, and potential limitations. No output schema and no annotations further reduce completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for all three parameters (prompt, voice, seed). The tool description does not add any additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Generate an audio response' to a 'text prompt', and mentions playing it through the system. It distinguishes from the sibling 'respondText' tool by specifying audio output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'listAudioVoices' or 'respondText'. The description lacks context on prerequisites or scenarios where audio generation is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

respondTextA

Respond with text to a prompt using the Pollinations Text API. User-configured settings in MCP config will be used as defaults unless specifically overridden.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe text prompt to generate a response for
modelNoModel to use for text generation (default: user config or "openai"). Use listTextModels to see all available models
seedNoSeed for reproducible results (default: random)
temperatureNoControls randomness in the output (0.0 to 2.0, default: user config or model default)
top_pNoControls diversity via nucleus sampling (0.0 to 1.0, default: user config or model default)
systemNoSystem prompt to guide the model's behavior (default: user config or none)

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the API name and default behavior but lacks details on response format, error handling, or rate limits. Minimal transparency beyond basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences efficiently convey the core function and default behavior. No unnecessary words, and the key action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a text generation tool with 6 params, the description covers defaults and model selection. However, without an output schema, it would benefit from describing the response format (e.g., returns text string). Still, it provides necessary context for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all 6 parameters (100% coverage). The description adds value by noting that defaults come from user config or model defaults, and suggests using listTextModels for available models, which goes beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates text responses via the Pollinations Text API using a prompt. It distinguishes from sibling tools like generateImage and respondAudio.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions default settings from user config can be overridden, providing clear usage context. However, it does not explicitly state when not to use this tool or recommend alternatives beyond listing sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.0
    • ChangededitImage5 fields changed
      • changedInput schema / properties / imageUrl / description
        Previous value: -"URL of the input image to edit"New value: +"Public HTTP(S) URL(s) of the input image(s) to edit. Accepts a string or an array for multiple references (first is most important). Local file paths, file uploads, or base64/data URLs are not supported."
      • addedInput schema / properties / imageUrl / oneOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]
      • removedInput schema / properties / imageUrl / type
        Removed value: -"string"
      • changedInput schema / properties / model / description
        Previous value: -"Model name to use for editing (default: user config or \"gptimage\"). Available: \"gptimage\", \"kontext\""New value: +"Model name to use for editing (default: user config or \"kontext\"). Available: \"kontext\", \"nanobanana\", \"seedream\""
      • removedInput schema / properties / transparent
        Removed value: -{
-  "description": "Generate image with transparent background (gptimage model only, default: false)",
-  "type": "boolean"
-}
    • ChangedgenerateImage1 field changed
      • removedInput schema / properties / transparent
        Removed value: -{
-  "description": "Generate image with transparent background (gptimage model only, default: false)",
-  "type": "boolean"
-}
    • ChangedgenerateImageFromReference5 fields changed
      • changedInput schema / properties / imageUrl / description
        Previous value: -"URL of the reference image to base the generation on"New value: +"Public HTTP(S) URL(s) of reference images. Accepts a string or an array for multi-reference. Local file paths, file uploads, or base64/data URLs are not supported."
      • addedInput schema / properties / imageUrl / oneOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]
      • removedInput schema / properties / imageUrl / type
        Removed value: -"string"
      • changedInput schema / properties / model / description
        Previous value: -"Model name to use for generation (default: user config or \"gptimage\"). Available: \"gptimage\", \"kontext\""New value: +"Model name to use for generation (default: user config or \"kontext\"). Available: \"kontext\", \"nanobanana\", \"seedream\""
      • removedInput schema / properties / transparent
        Removed value: -{
-  "description": "Generate image with transparent background (gptimage model only, default: false)",
-  "type": "boolean"
-}
    • ChangedgenerateImageUrl1 field changed
      • removedInput schema / properties / transparent
        Removed value: -{
-  "description": "Generate image with transparent background (gptimage model only, default: false)",
-  "type": "boolean"
-}
  2. 9 tool updates
    • First observededitImage
    • First observedgenerateImage
    • First observedgenerateImageFromReference
    • First observedgenerateImageUrl
    • First observedlistAudioVoices
    • First observedlistImageModels
    • First observedlistTextModels
    • First observedrespondAudio
    • First observedrespondText
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation3/5

The four image generation tools (generateImage, generateImageFromReference, generateImageUrl, editImage) have overlapping purposes; generateImage and generateImageUrl differ only in output format, which could confuse an agent. Audio and text tools are distinct, but the image subset reduces clarity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., editImage, generateImage, listAudioVoices, respondText). The naming is predictable and uses lowercase camelCase throughout, with no mixing of conventions.

Tool Count5/5

With 9 tools covering text, image, and audio generation along with model/voice listing, the count is well-scoped for a multimodal server. Each tool serves a clear, non-redundant role within the domain.

Completeness4/5

The tool set covers core generative capabilities (text, image, audio) and model introspection. Minor gaps exist, such as missing image-to-text or video generation, but these are not essential given the server's stated purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pinkpixel-dev/MCPollinations'

If you have feedback or need assistance with the MCP directory API, please join our Discord server