Skip to main content
Glama
hanoak

pixabay-mcp-server

by hanoak

pixabay-mcp-server

npm version npm downloads MCP Registry CI license: MIT node: >=20 PRs welcome

A Model Context Protocol (MCP) server for the Pixabay API. It gives AI assistants — Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, and any MCP client — tools to search and fetch royalty-free images and videos.

IMPORTANT

Unofficial project. This is not affiliated with, endorsed by, or sponsored by Pixabay. "Pixabay" is a trademark of its respective owner. You use it under your own Pixabay account and are responsible for complying with Pixabay's Terms of Service and Content License.

Table of contents

Related MCP server: UnSplashX

Features

  • 4 tools covering Pixabay's two documented endpoints — images (search, get) and videos (search, get). Pixabay has a single API-key auth tier and no write endpoints, so there's no partial "read-only v1" — this is the whole surface.

  • Compliance-aware by design — every outbound request is cached for 24 hours (Pixabay's terms require it, not an optimization), safesearch defaults to true, and the mandatory courtesy attribution (by {user} via Pixabay) is surfaced on every result even though Pixabay doesn't require it.

  • Real image & video URLs — search results return one balanced default size tier per item (webformatURL for images, the medium rendition for videos); looking a specific item up by id returns every size tier Pixabay provides, so you can pick what actually fits.

  • Token-efficient output — full Pixabay responses are trimmed to a compact shape (URLs + metadata as text, never base64 blobs), dropping vanity metrics (views/downloads/likes/ comments) that a model rarely needs.

  • Robust — typed failures returned as MCP isError results the model can recover from, plus a considered single retry with backoff on 429/5xx, network timeouts, and rate-limit-aware logging.

  • Safe — the Pixabay API key is redacted from every log line and error message (it can only ever be sent as a URL query parameter — Pixabay has no header alternative).

  • Lean & modern — ESM, Node 20+, zero-install via npx, no telemetry.

Quick start

1. Get a Pixabay API key

Sign up for a free account at pixabay.com — your API key is shown immediately on the API docs page once you're logged in, no approval step for the default tier this server uses.

2. Add the server to your MCP client

Claude Desktop — edit claude_desktop_config.json:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "pixabay": {
      "command": "npx",
      "args": ["-y", "@hanoak/pixabay-mcp-server"],
      "env": {
        "PIXABAY_API_KEY": "your_api_key"
      }
    }
  }
}

Restart the client. See Configuration for every supported variable.

Claude Code (CLI):

claude mcp add pixabay \
  --env PIXABAY_API_KEY=your_api_key \
  -- npx -y @hanoak/pixabay-mcp-server

Cursor~/.cursor/mcp.json (global) or .cursor/mcp.json (per-project): use the exact same mcpServers block as Claude Desktop above.

Windsurf~/.codeium/windsurf/mcp_config.json: same mcpServers block as Claude Desktop above.

VS Code.vscode/mcp.json (note the top-level key is servers, not mcpServers):

{
  "servers": {
    "pixabay": {
      "command": "npx",
      "args": ["-y", "@hanoak/pixabay-mcp-server"],
      "env": {
        "PIXABAY_API_KEY": "your_api_key"
      }
    }
  }
}

Any other MCP client — run the server over stdio with:

PIXABAY_API_KEY=your_api_key npx -y @hanoak/pixabay-mcp-server

Point your client's stdio transport at command: npx, args: ["-y", "@hanoak/pixabay-mcp-server"], and pass the key via env.

3. Try it

Restart your client and ask:

"Find me a photo of mountains on Pixabay."

Example interaction

A typical flow: the model calls pixabay_search_images, picks a result, and presents the image with its courtesy attribution.

You: Find a landscape photo of a foggy pine forest.

Assistant: (calls pixabay_search_images with query: "foggy pine forest", orientation: "horizontal", picks the best result) Here's a great match — by Josch13 via Pixabay — along with the image URL.

Each tool returns a compact JSON payload. Here's the shape of a single search result (illustrative values):

[
  {
    "id": 195893,
    "pageURL": "https://pixabay.com/en/blossom-bloom-flower-195893/",
    "type": "photo",
    "tags": "blossom, bloom, flower",
    "url": "https://pixabay.com/get/35bbf209e13e39d2_640.jpg",
    "width": 640,
    "height": 360,
    "user": "Josch13",
    "attribution": "by Josch13 via Pixabay"
  }
]

pixabay_get_image/pixabay_get_video return the same shape for a single item, but with every size tier Pixabay provides instead of just one — see Output shape.

Configuration

Configuration is entirely via environment variables — no config files, no flags for secrets.

Environment variable

Required

Description

PIXABAY_API_KEY

yes

Your Pixabay API key. The server exits at startup with a clear message if it is missing or blank.

LOG_LEVEL

no

debug | info | warn | error (default info). All logs go to stderr; stdout carries only the MCP protocol.

CLI flags: --version and --help are supported (e.g. npx @hanoak/pixabay-mcp-server --version).

Tools

All tools are namespaced pixabay_* and every one is read-only — Pixabay's API has no write endpoints, so a client can safely auto-approve the entire server. per_page is clamped to Pixabay's documented range of 3–200, and page is 1-based.

Domain

Tools

Images

pixabay_search_images, pixabay_get_image

Videos

pixabay_search_videos, pixabay_get_video

Tool reference

Tool

Parameters

Description

pixabay_search_images

query?, lang?, image_type? (all|photo|illustration|vector), orientation? (all|horizontal|vertical), category?, colors? (array), min_width?, min_height?, editors_choice?, safesearch? (default true), order? (popular|latest), page?, per_page? (3–200)

Keyword image search with filters. Omit query to browse a default set.

pixabay_get_image

id (required)

A single image by its numeric id, with every size tier.

Tool

Parameters

Description

pixabay_search_videos

query?, lang?, video_type? (all|film|animation), category?, min_width?, min_height?, editors_choice?, safesearch? (default true), order? (popular|latest), page?, per_page? (3–200)

Keyword video search with filters. Omit query to browse a default set.

pixabay_get_video

id (required)

A single video by its numeric id, with every size tier.

Videos support category but not colors/orientation — that's a real difference in Pixabay's own API, not an oversight.

Output shape

Tools return trimmed, token-efficient JSON rather than raw Pixabay responses:

  • Image search (pixabay_search_images) → id, pageURL, type, tags, one default url (webformatURL), width/height, user, attribution.

  • Image detail (pixabay_get_image) → the same fields, plus every size tier Pixabay provided for that item: previewURL, webformatURL, largeImageURL, fullHDURL.

  • Video search (pixabay_search_videos) → id, pageURL, type, tags, duration, one default url (the medium rendition), width/height, user, attribution.

  • Video detail (pixabay_get_video) → the same fields, plus a videos object with all four renditions Pixabay provides (tiny/small/medium/large, each with url/width/ height).

  • Vanity metrics (views, downloads, likes, comments) are dropped from every result — they're rarely useful to a model and add tokens for no benefit.

Resources & prompts

Beyond tools, the server also exposes:

  • Resources — a compact guide your client can pull in as context:

    • pixabay://guides/usage — license/attribution guidance, the hotlinking-in-conversation reasoning, content-safety notes, and the full-API-access-tier caveat.

  • Prompts — a ready-made task your client can surface directly:

    Prompt

    Arguments

    What it does

    find_media

    subject (required), media_type? (images|videos|both, default both)

    Search for a subject and present the best match(es) with courtesy attribution.

Example prompts

Natural-language asks that map cleanly onto the tools:

  • "Find a photo of a foggy forest at sunrise."

  • "Search Pixabay for 5 minimalist workspace illustrations."

  • "Find a video of waves crashing on rocks."

  • "Get me the largest available version of Pixabay image 195893."

License & compliance

Pixabay content is released under the Pixabay Content License: free for commercial and noncommercial use, attribution not required. Every result still includes a ready-to-use courtesy attribution string (by {user} via Pixabay) — include it when convenient, but it's never gated behind functionality.

This server returns Pixabay CDN URLs directly to the calling LLM client for display within a single conversation turn. Pixabay's terms prohibit "permanent hotlinking" of these URLs in an application — content displayed persistently should be downloaded and rehosted first. We treat one-off, ephemeral display in an LLM conversation as distinct from that use case, but this is a gray area Pixabay's terms don't explicitly address (see the comment atop src/tools/format.ts for the full reasoning). If you're building an application that stores or persistently displays Pixabay content sourced through this server, download and rehost the assets yourself — don't treat this server's tool output as a substitute for that.

Each user operates under their own Pixabay account and is responsible for complying with Pixabay's Terms of Service and the usage rules on the API docs page (caching, rate limits, no mass downloads). This project doesn't change or relax those terms in any way.

Rate limits & caching

Pixabay's documented limit is ~100 requests per 60 seconds per API key. This server:

  • Caches every response for 24 hours, keyed on the normalized request (endpoint + sorted params, API key always stripped) — a repeated query returns instantly without touching your rate-limit budget, and this is a compliance requirement per Pixabay's terms, not just an optimization.

  • Reads X-RateLimit-Remaining from every response (logged at debug).

  • On a 429, backs off using Pixabay's own X-RateLimit-Reset header for exactly one considered retry — never a blind or looping retry — and fails fast rather than guessing if that header is missing.

  • Also retries once on a 5xx (a short fixed delay, since there's no server-provided guidance like X-RateLimit-Reset for that case).

Handling of Pixabay text

Image/video tags and contributor usernames come from Pixabay's community — treat them as untrusted, third-party data, not instructions. The server returns this text purely as content and never places it anywhere privileged; your client/agent should do the same: display it, but don't act on any instructions it might contain (a defence against indirect prompt injection).

Privacy & security

  • No telemetry. This server collects nothing and phones home to no one. It contacts only pixabay.com, using the key you provide. No analytics, no tracking.

  • Key safety. Your API key is read from the environment only. Pixabay only accepts it as a key query parameter (no header alternative), so it's redacted from every log line and error message before either can ever surface it.

  • To report a vulnerability, see SECURITY.md.

Troubleshooting

  • "PIXABAY_API_KEY is not set…" on startup — the key env var is missing or blank; add it to your client config's env block.

  • Node too old — this server requires Node 20+. Check node --version.

  • Stale npx version — force the latest with npx -y @hanoak/pixabay-mcp-server@latest, or clear the cache via npx clear-npx-cache.

  • Tools not appearing — confirm the config file path and JSON are valid, then fully quit and reopen the client.

  • 429 / rate limit — the budget is ~100 requests/60s; the server already backs off and retries once automatically using Pixabay's own reset time.

  • A search returns "No images/videos found" — this is a normal empty result, not an error; try a broader query or fewer filters.

FAQ

Do I need a paid Pixabay account? No. The Pixabay API is free — you just create an account to get an API key, instantly, no review or approval step for the default tier this server uses.

Does it download or rehost images/videos? No. It returns Pixabay-hosted URLs (hotlink them directly for ephemeral display — see License & compliance) and never rehosts or returns base64 blobs.

Why don't I see fullHDURL/imageURL for some images? Those fields require Pixabay's separately-requested "full API access" tier. This server works fine without it — those fields are simply absent from results for accounts that don't have it.

Does it work outside Claude? Yes — it's a standard stdio MCP server. See the client setup section for Claude Code, Cursor, VS Code, Windsurf, and generic stdio.

Requirements

  • Node.js >= 20 (Node 18 is end-of-life).

  • A Pixabay API key.

Compatibility

Component

Supported

Node.js

20 and 22, tested in CI; >=20 required (enforced by engines and a runtime guard).

OS

Linux, macOS, and Windows (all tested in CI).

MCP SDK

@modelcontextprotocol/sdk ^1.30; the protocol version is negotiated with your client on connect.

Transport

stdio (HTTP/SSE may be added in a future release).

Roadmap

Full detail lives in docs/ROADMAP.md. In short: v1 covers Pixabay's entire documented API in one release — there's no OAuth tier to split a v2 behind. Future scope under consideration includes an MCP resource for licensing/attribution guidance and additional prompts.

Changes are tracked in CHANGELOG.md; the project follows Semantic Versioning.

Contributing

Contributions are welcome — see CONTRIBUTING.md and our Code of Conduct. It covers local setup, the test suite, testing tools by hand with the MCP Inspector, and the versioning/deprecation policy. To report a vulnerability, see SECURITY.md.

Contact & community

Maintained by Hanoak S. The fastest way to get help or propose a feature is to open an issue — it's public, searchable, and helps the whole community.

If this project helps you, a ⭐ on GitHub is appreciated — it aids discoverability for others looking for a Pixabay MCP server.

License

MIT © Hanoak S. Not affiliated with Pixabay.

Available Tools

4 tools
pixabay_get_imageGet Pixabay ImageA
Read-only

Fetch a single Pixabay image by id (e.g. one returned from pixabay_search_images), including every size tier Pixabay provides for it.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe Pixabay image id to retrieve, e.g. from a pixabay_search_images result.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already mark this as read-only, so the description's added detail about returning every size tier provides useful behavioral context beyond what annotations convey. It doesn't cover error cases or rate limits, but those are less critical given the read-only hint.

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?

Single sentence, front-loaded with the action and resource, no unnecessary words. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter fetch tool with read-only annotations and no output schema, the description covers the essential behavior: fetching a single image and returning all size tiers. It is adequately complete.

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%, and the description essentially restates that the id identifies the image. No new semantic detail is added, so baseline 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?

Clearly states it fetches a single Pixabay image by id, distinguishing it from search tools (which list images) and the video sibling. The phrase 'including every size tier' adds specific scope not visible from the tool name.

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?

Gives concrete context by noting the id comes from pixabay_search_images, implying appropriate use after searching. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for a simple fetch tool.

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

pixabay_get_videoGet Pixabay VideoA
Read-only

Fetch a single Pixabay video by id (e.g. one returned from pixabay_search_videos), including every size tier Pixabay provides for it.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe Pixabay video id to retrieve, e.g. from a pixabay_search_videos result.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare read-only and open-world; the description adds that the response contains every size tier, providing useful behavioral context beyond what annotations offer.

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?

A single concise sentence that is front-loaded with the verb and resource, and adds relevant detail without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read-only tool with clear annotations and no output schema, the description gives enough context about the return value (all size tiers) and usage 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 is 100% covering the id parameter, and the description repeats the same information without adding new semantic meaning, warranting the baseline score.

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 fetches a single video by ID, distinguishing it from search and image tools. It also specifies that all size tiers are included, making the scope precise.

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?

It clearly indicates when to use (when you have an ID from pixabay_search_videos), but doesn't explicitly state when not to use or name alternatives, though sibling tools imply them.

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

pixabay_search_imagesSearch Pixabay ImagesA
Read-only

Search Pixabay's library of royalty-free images by keyword and filters. Returns a token-efficient summary per match (one representative image URL plus metadata) — call pixabay_get_image with an id for the full set of size tiers.

ParametersJSON Schema
NameRequiredDescriptionDefault
langNoISO 639-1 language code for the search term. Defaults to "en".
pageNoPage number. Defaults to 1.
orderNoSort order. Defaults to "popular".
queryNoSearch term (max 100 characters). Omit to browse a default set of images.
colorsNoFilter by dominant color(s).
categoryNoFilter by content category.
per_pageNoResults per page, 3-200. Defaults to 20.
min_widthNoMinimum image width in pixels. Defaults to 0 (no minimum).
image_typeNoFilter by image type. Defaults to "all".
min_heightNoMinimum image height in pixels. Defaults to 0 (no minimum).
safesearchNoOnly return content suitable for all ages. Defaults to true here (Pixabay itself defaults to false) so this tool never surfaces explicit content unprompted.
orientationNoFilter by image orientation. Defaults to "all".
editors_choiceNoOnly return award-winning editors-choice images. Defaults to false.

TDQS

A4.2/5.0
Behavior4/5

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

With readOnlyHint and openWorldHint already in annotations, the description adds behavioral context by stating it returns a token-efficient summary (one representative URL plus metadata) and that get_image provides full size tiers. It does not disclose pagination counts or rate limits, but this is sufficient given the annotations.

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, front-loaded with the primary action and resource, followed by output behavior and a redirect to a sibling tool. No filler or repetition.

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?

With 13 parameters and no output schema, the description clarifies the return format ('token-efficient summary', 'one representative image URL plus metadata') and points to pixabay_get_image for complete data. This is adequate for a search tool, though it could mention pagination behavior explicitly; the schema covers that via page/per_page.

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 baseline is 3. The description only mentions 'keyword and filters' generically, adding no specific parameter meaning beyond what the schema already provides. Parameters like safesearch, orientation, and colors are fully documented in 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 uses a specific verb ('Search') and resource ('Pixabay's library of royalty-free images') with filters, clearly distinguishing from siblings. It also notes the token-efficient summary and follow-up call to pixabay_get_image, which differentiates it from the get and video search tools.

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 explicitly directs users to pixabay_get_image for full size tiers, providing a follow-up alternative. It implies use for image search rather than video search through the title and sibling context, but does not explicitly state when not to use it versus pixabay_search_videos.

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

pixabay_search_videosSearch Pixabay VideosA
Read-only

Search Pixabay's library of royalty-free videos by keyword and filters. Returns a token-efficient summary per match (one representative video URL plus metadata) — call pixabay_get_video with an id for the full set of size tiers.

ParametersJSON Schema
NameRequiredDescriptionDefault
langNoISO 639-1 language code for the search term. Defaults to "en".
pageNoPage number. Defaults to 1.
orderNoSort order. Defaults to "popular".
queryNoSearch term (max 100 characters). Omit to browse a default set of videos.
categoryNoFilter by content category.
per_pageNoResults per page, 3-200. Defaults to 20.
min_widthNoMinimum video width in pixels. Defaults to 0 (no minimum).
min_heightNoMinimum video height in pixels. Defaults to 0 (no minimum).
safesearchNoOnly return content suitable for all ages. Defaults to true here (Pixabay itself defaults to false) so this tool never surfaces explicit content unprompted.
video_typeNoFilter by video type. Defaults to "all".
editors_choiceNoOnly return award-winning editors-choice videos. Defaults to false.

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the readOnlyHint annotation, the description discloses that the tool returns a token-efficient summary with one representative video URL plus metadata, not the full size tiers. This adds valuable behavioral context about the output shape and resource efficiency.

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 exactly two sentences, front-loaded with the core purpose followed by essential behavioral guidance. Every word adds value, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter search tool with rich schema annotations and readOnlyHint, the description explains the return format and directs to get_video for full details. It provides sufficient context for an agent to invoke the tool correctly even without an output schema.

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% with detailed descriptions for all 11 parameters, so the description need not explain them individually. The generic mention of 'keyword and filters' adds no extra meaning beyond what the schema already provides.

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 specifies the tool searches Pixabay's royalty-free video library by keyword and filters, using a specific verb and resource. It distinguishes itself from sibling tools like pixabay_get_video, which retrieves full video size tiers for a specific ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly directs users to call pixabay_get_video with an id for the full set of size tiers after receiving the summary, providing an alternative for complete data retrieval. This establishes when to use this search tool versus the get companion.

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

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a unique combination of action (search/get) and resource type (image/video), so there is no overlap or ambiguity. An agent can easily distinguish pixabay_search_images from pixabay_get_image.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with a common prefix (pixabay_), using snake_case throughout. The convention is uniform and predictable.

Tool Count5/5

Four tools is an ideal scope for a media search-and-retrieve server, covering the essential operations without redundancy. Each tool serves a distinct purpose.

Completeness5/5

The tool surface fully covers the core lifecycle for a read-only media API: search both images and videos, then fetch full details by ID. No obvious missing operations are needed for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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/hanoak/pixabay-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server