Allows AI assistants to search for photos, illustrations, vectors, videos, and animations on the Pixabay platform.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pixabay MCP Server find high-quality photos of a mountain landscape at sunset"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants to search for images and videos on Pixabay.
🖼️ search_images - Search for photos, illustrations, and vectors
🎬 search_videos - Search for videos and animations
The easiest way to use this MCP server is with uvx. No manual cloning required!
Get your Pixabay API Key
Add the following to your MCP client configuration:
{
"mcpServers": {
"pixabay": {
"command": "uvx",
"args": [
"https://github.com/helloHupc/pixabay_mcp.git"
],
"env": {
"PIXABAY_API_KEY": "your-api-key-here"
}
}
}
}Restart your MCP client and start using!
For development or to customize the code, clone the repository locally:
git clone https://github.com/helloHupc/pixabay_mcp.git
cd pixabay_mcpThen configure your MCP client:
{
"mcpServers": {
"pixabay": {
"command": "uv",
"args": [
"run",
"--directory", "/path/to/pixabay_mcp",
"python", "src/pixabay_mcp/server.py"
],
"env": {
"PIXABAY_API_KEY": "your-api-key-here"
}
}
}
}Make sure to replace /path/to/pixabay_mcp with your actual local path.
Create a free account at Pixabay
Go to API Documentation and copy your API key
Get your API key from Pixabay
Copy configuration from Method 1 above
Replace your-api-key-here with your actual API key
Add to your MCP client settings
Restart your MCP client
Start searching!
Once configured, you can ask your AI assistant:
"Search for photos of yellow flowers"
"Find some nature videos"
"Look for vector illustrations of cats"
pixabay_mcp/
├── src/
│ └── pixabay_mcp/
│ ├── __init__.py
│ └── server.py # Main MCP server implementation
├── pyproject.toml # Project configuration
├── uv.lock # Dependency lock file
├── README.md # This file
├── LICENSE # MIT License
└── .gitignore # Git ignore rulesMIT License
Related MCP server: Pixabay MCP Server
一个 MCP (Model Context Protocol) 服务，让 AI 助手能够在 Pixabay 上搜索图片和视频。
🖼️ search_images - 搜索照片、插画和矢量图
🎬 search_videos - 搜索视频和动画
最简单的使用方式，使用 uvx 直接从 Gitee 运行，无需手动克隆！
获取你的 Pixabay API 密钥
在 MCP 客户端配置中添加以下内容：
{
"mcpServers": {
"pixabay": {
"command": "uvx",
"args": [
"https://github.com/helloHupc/pixabay_mcp.git"
],
"env": {
"PIXABAY_API_KEY": "你的API密钥"
}
}
}
}重启 MCP 客户端，开始使用！
用于开发或自定义代码，将仓库克隆到本地：
git clone https://github.com/helloHupc/pixabay_mcp.git
cd然后配置 MCP 客户端：
{
"mcpServers": {
"pixabay": {
"command": "uv",
"args": [
"run",
"--directory", "/path/to/pixabay_mcp",
"python", "src/pixabay_mcp/server.py"
],
"env": {
"PIXABAY_API_KEY": "你的API密钥"
}
}
}
}请将 /path/to/pixabay_mcp 替换为你的实际本地路径。
从 Pixabay 获取你的 API 密钥
复制上面方法 1 中的配置
将 你的API密钥 替换为你的实际 API 密钥
添加到你的 MCP 客户端设置
重启 MCP 客户端
开始搜索！
配置完成后，你可以这样问 AI 助手：
"帮我搜索黄色花朵的图片"
"找一些自然风景的视频"
"搜索猫咪的矢量插画"
pixabay_mcp/
├── src/
│ └── pixabay_mcp/
│ ├── __init__.py
│ └── server.py # MCP 服务器主实现
├── pyproject.toml # 项目配置文件
├── uv.lock # 依赖锁定文件
├── README.md # 本文件
├── LICENSE # MIT 许可证
└── .gitignore # Git 忽略规则uv - 通用 Python 项目管理工具
用于开发、安装包、运行脚本
需要手动管理虚拟环境
适合本地开发和调试
uvx - 快速执行工具
直接从 PyPI 或 Git 仓库运行包
自动管理隔离环境
无需手动安装，开箱即用
适合快速部署和分享
MIT 许可证
Search for images on Pixabay.
Args:
query: Search term (e.g., "yellow flowers", "cat")
image_type: Filter by type - "all", "photo", "illustration", "vector"
orientation: Filter by orientation - "all", "horizontal", "vertical"
category: Filter by category - backgrounds, fashion, nature, science, education, feelings, health, people, religion, places, animals, industry, computer, food, sports, transportation, travel, buildings, business, music
colors: Filter by colors (comma-separated) - grayscale, transparent, red, orange, yellow, green, turquoise, blue, lilac, pink, white, gray, black, brown
per_page: Number of results per page (3-200)
page: Page number
safesearch: Enable safe search filter
Returns:
Search results with image URLs and metadata
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| image_type | No | all | |
| orientation | No | all | |
| category | No | ||
| colors | No | ||
| per_page | No | ||
| page | No | ||
| safesearch | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Search for images on Pixabay' and returns 'Search results with image URLs and metadata,' which implies a read-only operation but lacks details on permissions, rate limits, pagination behavior, or error handling. For a tool with 8 parameters and no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by detailed parameter explanations and a returns section. Every sentence adds value, but it could be more front-loaded by emphasizing the tool's core function before listing parameters. However, it avoids redundancy and is efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, but with an output schema), the description is mostly complete. It thoroughly documents parameters and states the return format, and the output schema likely covers return values, reducing the need for detailed output explanations. However, it lacks behavioral context like rate limits or authentication needs, which are important for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains each parameter's purpose with examples and constraints (e.g., 'query: Search term (e.g., "yellow flowers", "cat")', 'per_page: Number of results per page (3-200)'), compensating fully for the schema's lack of descriptions. This is essential for understanding how to use the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for images on Pixabay.' It specifies the verb ('search') and resource ('images on Pixabay'), making the action and target explicit. However, it does not differentiate from its sibling tool 'search_videos' (which searches videos on Pixabay), so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the sibling tool 'search_videos' or any other tools, nor does it specify contexts or exclusions for usage. The only implied usage is for searching images, but no explicit alternatives or constraints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for videos on Pixabay.
Args:
query: Search term (e.g., "nature", "city")
video_type: Filter by type - "all", "film", "animation"
category: Filter by category - backgrounds, fashion, nature, science, education, feelings, health, people, religion, places, animals, industry, computer, food, sports, transportation, travel, buildings, business, music
per_page: Number of results per page (3-200)
page: Page number
safesearch: Enable safe search filter
Returns:
Search results with video URLs and metadata
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| video_type | No | all | |
| category | No | ||
| per_page | No | ||
| page | No | ||
| safesearch | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the tool searches for videos and returns results with URLs/metadata, but doesn't describe rate limits, authentication requirements, pagination behavior beyond parameters, error conditions, or what constitutes a successful search. The description is minimal and lacks important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It starts with the core purpose, then provides a cleanly formatted parameter section with clear explanations, and ends with return value information. Every sentence earns its place with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), the description provides good context for a search tool. It covers all parameters thoroughly and states the basic purpose. However, it lacks important behavioral context like rate limits, authentication needs, or error handling that would be valuable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics despite 0% schema description coverage. It explains what each parameter does with clear examples and constraints: 'query: Search term (e.g., "nature", "city")', 'per_page: Number of results per page (3-200)', and lists all valid values for video_type and category. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for videos on Pixabay.' It specifies the resource (videos) and platform (Pixabay), but doesn't explicitly differentiate from its sibling tool 'search_images' beyond the resource type. The purpose is clear but lacks explicit sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'search_images' or explain when to search for videos versus images. There's no context about use cases, prerequisites, or limitations beyond basic parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: one searches for images and the other searches for videos. There is no overlap in functionality, and the descriptions explicitly differentiate between media types, making it impossible for an agent to confuse them.
Both tools follow a consistent verb_noun pattern with 'search_' prefix followed by the media type (images/videos). The naming is perfectly uniform and predictable across the tool set.
With only two tools, this server feels thin for a media search service. While search is core, there are obvious gaps like fetching specific media by ID, getting trending content, or managing downloads. The count is too low for comprehensive coverage of the Pixabay domain.
The tool surface is severely incomplete for a Pixabay API server. It only provides search functionality, missing essential operations like retrieving specific images/videos by ID, getting user uploads, or accessing categories/trends. Agents will hit dead ends when trying to perform basic media retrieval tasks beyond searching.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate AI images, videos, music, SFX & speech in any AI assistant. Results appear inline in chat.
Create images and videos from prompts, with options for image mixing, reference images, and start/…
15 media & data tools for AI agents: search, transcribe, subtitles, voiceover, translate & more.
Upload, organize, search, and transform images, videos, and files with AI-powered tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/helloHupc/pixabay_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
