Skip to main content
Glama
enesjakozh
pinkpixel-dev

MCPollinations Multimodal MCP Server

by pinkpixel-dev
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

MCPolinations マルチモーダル MCP サーバー

鍛冶屋のバッジ AIアシスタントがPollinations APIを通じて画像、テキスト、音声を生成できるようにするモデルコンテキストプロトコル（MCP）サーバー

特徴

  • テキストプロンプトから画像の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ポリフィルを使用します

クイックスタート

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を手動でインストールします:

    • 何らかの理由でポリフィルが機能しない場合: 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サーバーが実行している現在の作業ディレクトリです。

  • デフォルトでは「フラックス」モデルが使用されます

  • 各画像に対してデフォルトでランダムシードが生成されます（多様性を確保）

  • 画像がファイルに保存されているかどうかに関係なく、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. イメージは、Claude またはクライアント アプリケーションがインストールされている場所ではなく、MCP サーバーが実行されている現在の作業ディレクトリに保存されます。

  2. 特定のディレクトリから MCP サーバーを手動で起動すると、画像はデフォルトでそこに保存されます。

  3. Claude Desktop が MCP サーバーを自動的に起動すると、画像は Claude Desktop の作業ディレクトリ (通常はアプリケーション データ フォルダー) に保存されます。

生成された画像を見つける

  • 画像を生成した後のクロードからの応答には、画像が保存されたファイルの完全なパスが含まれています。

  • outputPathパラメータを使用して、使い慣れた場所を指定できます。

  • ベストプラクティス: クロードに、画像やダウンロードディレクトリなどの簡単にアクセスできるフォルダに画像を保存するように依頼します。

ユニークなファイル名

MCP サーバーは、生成された画像が常に一意のファイル名を持ち、既存のファイルを上書きしないことを保証します。

  1. デフォルトのファイル名は次のとおりです。

    • プロンプトのサニタイズされたバージョン（最初の20文字）

    • タイムスタンプ

    • ランダムな接尾辞

  2. カスタム ファイル名も保護されます。

    • ファイル名を指定し、その名前のファイルがすでに存在する場合は、数字の接尾辞が自動的に追加されます。

    • たとえば、 sunset.png 、 sunset_1.png 、 sunset_2.pngなどです。

つまり、以前の画像を上書きすることを心配することなく、同じプロンプトまたはファイル名を持つ複数の画像を安全に生成できます。

Base64データへのアクセス

ファイルに保存する場合でも、base64 でエンコードされた画像データが常に返され、次の目的で使用できます。

  • Web ページへの埋め込み ( <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