Skip to main content
Glama
ddunford

ElevenLabs Image Generation MCP Server

by ddunford
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ElevenLabs Image Generation MCP Server

An MCP (Model Context Protocol) server that generates images using ElevenLabs' Image & Video feature via Playwright browser automation.

Features

  • generate_image - Generate images from text prompts using ElevenLabs

  • list_models - List available image generation models

  • get_session_status - Check authentication status

Related MCP server: Google Flow Browser MCP

Available Models

Model ID

Name

Description

gpt-image-1.5

GPT Image 1.5 (default)

OpenAI - precise, high-quality generation

gpt-image-1

GPT Image 1

OpenAI - text-based creation and editing

flux-kontext-pro

Flux 1 Kontext Pro

Professional style control via reference images

seedream-4

Seedream 4

Multi-shot sequences with stable physics

nano-banana

Nano Banana (Google)

High-speed iterations

wan-2.5

Wan 2.5

Strong prompt fidelity

Installation

# Clone the repository
git clone git@github.com:ddunford/elevenlabMCP.git
cd elevenlabMCP

# Install dependencies
npm install

# Build
npm run build

# Install Playwright browser
npx playwright install chromium

Quick Setup (One-Liner)

Add to Claude Code globally:

claude mcp add elevenlabs-image -s user -- node /path/to/elevenlabMCP/dist/index.js

Or manually add to ~/.claude.json:

{
  "mcpServers": {
    "elevenlabs-image": {
      "type": "stdio",
      "command": "node",
      "args": ["/path/to/elevenlabMCP/dist/index.js"],
      "env": {}
    }
  }
}

Usage

In Claude Code

After adding the MCP server, restart Claude Code. The tools will be available as:

  • mcp__elevenlabs-image__generate_image

  • mcp__elevenlabs-image__list_models

  • mcp__elevenlabs-image__get_session_status

generate_image

Generate an image from a text prompt.

Parameters:

Parameter

Required

Description

prompt

Yes

Text description of the image to generate

model

No

Model ID (default: gpt-image-1.5)

savePath

No

Directory to save image (default: assets/)

aspectRatio

No

e.g., "1:1", "16:9", "9:16"

negativePrompt

No

What to avoid in the image

email

No

ElevenLabs account email (for first-time auth)

password

No

ElevenLabs account password (for first-time auth)

Example:

Generate an image of a cyberpunk city at night with neon lights

list_models

Returns all available image generation models with their capabilities.

get_session_status

Check if currently logged in to ElevenLabs.

Authentication

On first use, provide your ElevenLabs credentials via the email and password parameters. The session is persisted in .auth/ so subsequent calls don't require credentials.

How It Works

  1. Uses Playwright to automate the ElevenLabs web interface (no API available for image generation)

  2. Maintains a persistent browser session for authentication

  3. Navigates to the Image & Video page

  4. Enters prompts and generates images

  5. Downloads generated images from the History page

Project Structure

elevenlabMCP/
├── src/
│   ├── index.ts              # Entry point
│   ├── server.ts             # MCP server setup
│   ├── tools/                # MCP tool implementations
│   ├── browser/              # Playwright automation
│   ├── auth/                 # Authentication handling
│   └── config/               # Configuration
├── dist/                     # Compiled JavaScript
├── assets/                   # Generated images output
└── .auth/                    # Session storage (gitignored)

Environment Variables (Optional)

Create a .env file:

ELEVENLABS_EMAIL=your@email.com
ELEVENLABS_PASSWORD=yourpassword
HEADLESS=true  # Set to false for debugging

Notes

  • Image generation typically takes 30-60 seconds

  • Generated images are saved as WebP files

  • The browser runs headless by default; set HEADLESS=false to see the browser

License

MIT

Available Tools

3 tools
generate_imageA

Generate an image using ElevenLabs Image & Video feature. Returns the path to the downloaded image file.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailNoElevenLabs account email (for authentication if not logged in)
modelNoModel to use. Options: gpt-image-1.5, gpt-image-1, flux-kontext-pro, seedream-4, nano-banana, wan-2.5. Default: gpt-image-1.5
promptYesThe text prompt describing the image to generate
passwordNoElevenLabs account password (for authentication if not logged in)
savePathNoDirectory to save the image. Default: /app/assets
aspectRatioNoAspect ratio (e.g., "1:1", "16:9", "9:16")
negativePromptNoWhat to avoid in the generated image

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description must disclose behavior fully. It mentions file path return and uses ElevenLabs feature, but does not discuss authentication requirements, error handling, or potential side effects. The description is adequate but not detailed.

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 two sentences, no wasted words, and directly states the core purpose and output. It is well-structured 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 7 parameters (1 required) and no output schema, the description explains the return value (file path) and mentions the ElevenLabs feature. It could add more detail about saving behavior or default directory, but is mostly complete.

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 description coverage is 100%, so baseline is 3. The description adds value by stating the tool returns a file path, and it mentions 'using ElevenLabs Image & Video feature', which gives context beyond the schema. Scores 4.

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 explicitly states 'Generate an image using ElevenLabs Image & Video feature' and mentions the return value 'path to the downloaded image file'. It clearly distinguishes from sibling tools like get_session_status and list_models, which are unrelated.

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 implies usage for image generation but does not provide explicit guidance on when to use versus alternatives, nor does it mention prerequisites or limitations. The sibling tools are unrelated, reducing the need for differentiation, but still no exclusions are given.

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

get_session_statusA

Check if currently logged in to ElevenLabs and get session information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It mentions checking login and getting session info, but does not specify side effects (likely none), required permissions, or whether the operation is read-only. Adequate but not thorough.

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 concise sentence, front-loading the action. No unnecessary words.

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 no output schema and no annotations, the description provides the essential purpose but lacks detail on return format or session information content. Could be more complete for a simple tool.

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 no parameters, and schema coverage is 100% (trivially). Description adds no parameter info, which is acceptable. Baseline for 0 params is 4.

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 checks login status and gets session info. It distinguishes from siblings (generate_image, list_models) which are unrelated, making the specific verb+resource clear.

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 implies use for checking authentication, but does not explicitly state when to use versus alternatives or provide exclusion criteria. No guidance on preconditions or when not to use.

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

list_modelsA

List all available image generation models on ElevenLabs

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/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 full burden. It correctly implies a read-only operation ('List') but does not disclose potential behavioral traits such as caching, rate limits, or idempotency. For a straightforward list function, this is marginally sufficient.

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, clear sentence with no unnecessary words. It front-loads the action and resource, earning its place efficiently.

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 no output schema or parameters, the description is largely complete for a list tool. However, it could add minor context about typical use (e.g., to check available models before generating) to enhance completeness. Score 4.

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 trivially 100% as there are no parameters. The description adds no parameter semantics, which is acceptable since no parameters exist. Score at baseline 3.

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', the resource 'image generation models', and the scope 'on ElevenLabs'. It directly conveys the tool's function and is easily distinguishable from sibling tools like generate_image and get_session_status.

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 implies usage context (listing models before generating images) but does not explicitly provide when or when-not to use, nor does it mention alternatives. For a simple list tool, this is adequate but lacks explicit guidance.

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. 3 tool updatesv1.0.0
    • First observedgenerate_image
    • First observedget_session_status
    • First observedlist_models
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

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: generating images, checking session status, and listing models. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: generate_image, get_session_status, list_models.

Tool Count5/5

Three tools is appropriate for a focused image generation server, covering essential actions without being too sparse or bloated.

Completeness4/5

The set covers the core image generation workflow (list models, check session, generate) but lacks tools for managing or retrieving past generations, leaving minor gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers