Skip to main content
Glama
enesjakozh
pinkpixel-dev

MCPollinations Multimodal MCP Server

by pinkpixel-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Servidor MCP multimodal MCPollinations

insignia de herrería Un servidor de Protocolo de Contexto de Modelo (MCP) que permite a los asistentes de IA generar imágenes, texto y audio a través de las API de polinización.

Características

  • Generar URL de imágenes a partir de indicaciones de texto

  • Genera imágenes y devuélvelas como datos codificados en base64 Y guárdalas como png, jpeg, jpg o webp (predeterminado: png)

  • Generar respuestas de texto a partir de indicaciones de texto

  • Generar respuestas de audio a partir de indicaciones de texto

  • Lista de modelos de generación de imágenes y texto disponibles

  • No se requiere autenticación

  • Sencillo y ligero

  • Compatible con el Protocolo de Contexto de Modelo (MCP)

Related MCP server: GPT Image 1 MCP

Requisitos del sistema

  • Node.js : Versión 14.0.0 o superior

    • Para un mejor rendimiento, recomendamos Node.js 16.0.0 o superior

    • Las versiones de Node.js anteriores a la 16 utilizan un polyfill AbortController

Inicio rápido

Instalación mediante herrería

Para instalar mcpollinations para Claude Desktop automáticamente a través de Smithery :

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

La forma más sencilla de utilizar el servidor MCP:

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

Si prefieres instalarlo globalmente:

# Install globally
npm install -g @pinkpixel/mcpollinations

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

O clonar el repositorio:

# 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

Integración MCP

Para integrar el servidor con aplicaciones que admiten el Protocolo de contexto de modelo (MCP):

  1. Generar un archivo de configuración MCP:

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

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

  1. Siga las instrucciones para personalizar su configuración o utilizar los valores predeterminados.

    • Establezca una salida personalizada y directorios temporales (el valor predeterminado son rutas relativas para portabilidad)

    • Configurar parámetros predeterminados para la generación de imágenes (con una lista de modelos disponibles, dimensiones, etc.)

    • Configurar parámetros predeterminados para la generación de texto (con una lista de modelos disponibles)

    • Configurar parámetros predeterminados para la generación de audio (voz)

    • Especificar qué herramientas deben estar permitidas

  2. Copie el archivo mcp.json generado al archivo .json de configuración MCP de su aplicación.

  3. Reinicie su aplicación.

Después de la integración, puedes usar comandos como:

Genera una imagen de una puesta de sol sobre el océano usando MCPollinations.

Solución de problemas

Error "AbortController no está definido"

Si encuentra este error al ejecutar el servidor MCP:

ReferenceError: AbortController is not defined

Esto suele deberse a una versión anterior de Node.js (anterior a la 16.0.0). Pruebe una de estas soluciones:

  1. Actualizar Node.js (recomendado):

    • Actualice a Node.js 16.0.0 o más reciente

  2. Utilizar la instalación global

    • Actualización a la última versión del paquete: GXP7

  3. Instalar AbortController manualmente :

    • Si por alguna razón el polyfill no funciona: GXP8

Comprueba tu versión de Node.js

Para comprobar su versión actual de Node.js:

node --version

Si muestra una versión inferior a 16.0.0, considere actualizar para obtener una mejor compatibilidad.

Herramientas disponibles

El servidor MCP proporciona las siguientes herramientas:

  1. generateImageUrl : genera una URL de imagen a partir de un mensaje de texto.

  2. generateImage : genera una imagen, la devuelve como datos codificados en base64 y la guarda en un archivo de forma predeterminada (formato PNG)

  3. respondAudio : genera una respuesta de audio a una solicitud de texto (parámetro de voz personalizable)

  4. respondText : responde con texto a una solicitud utilizando modelos de texto (parámetro de modelo personalizable)

  5. listImageModels : enumera los modelos disponibles para la generación de imágenes

  6. listTextModels : enumera los modelos disponibles para la generación de texto

  7. listAudioVoices : enumera todas las voces disponibles para la generación de audio

Detalles de generación de imágenes

Comportamiento predeterminado

Al utilizar la herramienta generateImage :

  • Las imágenes se guardan en el disco de forma predeterminada como archivos PNG

  • La ubicación de guardado predeterminada es el directorio de trabajo actual donde se ejecuta el servidor MCP

  • El modelo 'flujo' se utiliza por defecto

  • Se genera una semilla aleatoria de forma predeterminada para cada imagen (lo que garantiza la variedad)

  • Los datos de imagen codificados en Base64 siempre se devuelven, independientemente de si la imagen está guardada en un archivo

Personalización de la generación de imágenes

// Example options for generateImage
const options = {
  // Model selection (defaults to 'flux')
  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
};

Dónde se guardan las imágenes

Al utilizar Claude u otra aplicación con el servidor MCP:

  1. Las imágenes se guardan en el directorio de trabajo actual donde se ejecuta el servidor MCP , no donde está instalado Claude o la aplicación cliente.

  2. Si inicia el servidor MCP manualmente desde un directorio específico, las imágenes se guardarán allí de forma predeterminada.

  3. Si Claude Desktop inicia el servidor MCP automáticamente, las imágenes se guardarán en el directorio de trabajo de Claude Desktop (normalmente en una carpeta de datos de la aplicación).

Cómo encontrar las imágenes generadas

  • La respuesta de Claude después de generar una imagen incluye la ruta completa del archivo donde se guardó la imagen

  • Puede especificar una ubicación familiar utilizando el parámetro outputPath

  • Práctica recomendada: pídale a Claude que guarde las imágenes en una carpeta de fácil acceso, como su directorio de Imágenes o Descargas.

Nombres de archivos únicos

El servidor MCP garantiza que las imágenes generadas siempre tengan nombres de archivo únicos y nunca sobrescribirán los archivos existentes:

  1. Los nombres de archivo predeterminados incluyen:

    • Una versión desinfectada del mensaje (primeros 20 caracteres)

    • Una marca de tiempo

    • Un sufijo aleatorio

  2. Los nombres de archivos personalizados también están protegidos:

    • Si especifica un nombre de archivo y ya existe un archivo con ese nombre, se agregará automáticamente un sufijo numérico

    • Por ejemplo: sunset.png , sunset_1.png , sunset_2.png , etc.

Esto significa que puede generar de forma segura múltiples imágenes con el mismo mensaje o nombre de archivo sin preocuparse por sobrescribir las imágenes anteriores.

Acceso a datos Base64

Incluso al guardar en un archivo, los datos de imagen codificados en base64 siempre se devuelven y se pueden usar para:

  • Incrustar en páginas web ( <img src="data:image/png;base64,..." /> )

  • Pasar a otros servicios o API

  • Procesamiento en memoria sin operaciones del sistema de archivos

  • Visualización en aplicaciones que admiten URI de datos

Para desarrolladores

Si desea utilizar el paquete en sus propios proyectos:

# 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.

  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
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 9 tools

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

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches