Skip to main content
Glama
enesjakozh
pinkpixel-dev

MCPollinations Multimodal MCP Server

by pinkpixel-dev
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

MCPollinations 多模式 MCP 服务器

铁匠徽章模型上下文协议 (MCP) 服务器，使 AI 助手能够通过 Pollinations API 生成图像、文本和音频

特征

  • 根据文本提示生成图像 URL

  • 生成图像并将其作为 base64 编码数据返回并保存为 png、jpeg、jpg 或 webp（默认值：png）

  • 根据文本提示生成文本响应

  • 根据文本提示生成音频响应

  • 列出可用的图像和文本生成模型

  • 无需身份验证

  • 简单轻量

  • 与模型上下文协议（MCP）兼容

Related MCP server: GPT Image 1 MCP

系统要求

  • Node.js ：版本 14.0.0 或更高版本

    • 为了获得最佳性能，我们建议使用 Node.js 16.0.0 或更高版本

    • Node.js 16 以下版本使用 AbortController polyfill

快速入门

通过 Smithery 安装

要通过Smithery自动为 Claude Desktop 安装 mcpollinations：

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

使用 MCP 服务器最简单的方法：

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

如果您希望全局安装它：

# Install globally
npm install -g @pinkpixel/mcpollinations

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

或者克隆存储库：

# 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 集成

要将服务器与支持模型上下文协议 (MCP) 的应用程序集成：

  1. 生成 MCP 配置文件：

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

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

  1. 按照提示自定义配置或使用默认配置。

    • 设置自定义输出和临时目录（为了便于移植，默认为相对路径）

    • 配置图像生成的默认参数（包含可用模型、尺寸等的列表）

    • 配置文本生成的默认参数（包含可用模型列表）

    • 配置音频生成（语音）的默认参数

    • 指定应允许哪些工具

  2. 将生成的mcp.json文件复制到应用程序的 MCP 设置 .json 文件中。

  3. 重新启动您的应用程序。

集成后，您可以使用以下命令：

“使用 MCPollinations 生成海上日落图像”

故障排除

“AbortController 未定义”错误

如果您在运行 MCP 服务器时遇到此错误：

ReferenceError: AbortController is not defined

这通常是由于运行了旧版本的 Node.js（低于 16.0.0 版本）导致的。请尝试以下解决方案之一：

  1. 更新 Node.js （推荐）：

    • 更新至 Node.js 16.0.0 或更高版本

  2. 使用全局安装

    • 更新软件包至最新版本：GXP7

  3. 手动安装 AbortController ：

    • 如果由于某种原因 polyfill 不起作用：GXP8

检查您的 Node.js 版本

要检查当前的 Node.js 版本：

node --version

如果显示的版本低于 16.0.0，请考虑升级以获得最佳兼容性。

可用工具

MCP 服务器提供以下工具：

  1. generateImageUrl - 根据文本提示生成图像 URL

  2. generateImage - 生成图像，将其作为 base64 编码数据返回，并默认将其保存到文件中（PNG 格式）

  3. respondAudio - 根据文本提示生成音频响应（可自定义语音参数）

  4. respondText - 使用文本模型（可定制的模型参数）以文本形式响应提示

  5. listImageModels - 列出可用于图像生成的模型

  6. listTextModels - 列出可用于文本生成的模型

  7. listAudioVoices - 列出所有可用于音频生成的声音

图像生成详细信息

默认行为

使用generateImage工具时：

  • 图像默认以 PNG 文件形式保存到磁盘

  • 默认保存位置是 MCP 服务器正在运行的当前工作目录

  • 默认使用“flux”模型

  • 默认为每张图片生成一个随机种子（确保多样性）

  • 无论图像是否保存到文件，始终返回 Base64 编码的图像数据

自定义图像生成

// 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
};

图像保存在哪里

当使用 Claude 或其他应用程序与 MCP 服务器时：

  1. 图像保存在 MCP 服务器运行的当前工作目录中，而不是安装 Claude 或客户端应用程序的目录中。

  2. 如果您从特定目录手动启动 MCP 服务器，图像将默认保存在那里。

  3. 如果 Claude Desktop 自动启动 MCP 服务器，图像将保存在 Claude Desktop 的工作目录中（通常在应用程序数据文件夹中）。

查找生成的图像

  • 生成图像后，Claude 的响应包含保存图像的完整文件路径

  • 您可以使用outputPath参数指定熟悉的位置

  • 最佳实践：让 Claude 将图片保存到易于访问的文件夹，例如图片或下载目录

唯一文件名

MCP 服务器确保生成的图像始终具有唯一的文件名，并且永远不会覆盖现有文件：

  1. 默认文件名包括：

    • 提示的净化版本（前 20 个字符）

    • 时间戳

    • 随机后缀

  2. 自定义文件名也受到保护：

    • 如果您指定文件名并且该名称的文件已经存在，则会自动添加数字后缀

    • 例如： sunset.png 、 sunset_1.png 、 sunset_2.png等。

这意味着您可以安全地使用相同的提示或文件名生成多个图像，而不必担心覆盖以前的图像。

访问 Base64 数据

即使保存到文件，也始终返回 base64 编码的图像数据，并且可以用于：

  • 嵌入网页（ <img src="data:image/png;base64,..." /> ）

  • 传递给其他服务或 API

  • 无需文件系统操作即可在内存中进行处理

  • 在支持数据 URI 的应用程序中显示

对于开发人员

如果您想在自己的项目中使用该包：

# 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