How do I use pexels-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pexels-mcp-server search for photos of sunrise" 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.

pexels-mcp-server

Q: Which integrations are available for this server?

Provides tools for searching and retrieving photos, videos, and collections from the Pexels API.

by garylab

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Pexels MCP Server

PyPI version PyPI downloads Total downloads Python version

A Model Context Protocol server that provides access to the Pexels API for searching and retrieving photos, videos, and collections.

Available Tools

photos_search – Search photos
photos_curated – List curated photos
photo_get – Get a photo by id
videos_search – Search videos
videos_popular – List popular videos
video_get – Get a video by id
collections_featured – List featured collections
collections_media – List media in a collection

Related MCP server: Lorem Ipsum MCP Server

Usage

Using `uv` (recommended)

Install uv.

In your MCP client code configuration or Claude settings (file claude_desktop_config.json) add pexels mcp server:

{
    "mcpServers": {
        "pexels": {
            "command": "uvx",
            "args": ["pexels-mcp-server"],
            "env": {
                "PEXELS_API_KEY": "<Your Pexels API key>"
            }
        }
    }
}

uv will download the MCP server automatically using uvx from pypi.org and apply to your MCP client.

Using `pip` for a project

Add pexels-mcp-server to your MCP client code requirements.txt file.
```
pexels-mcp-server
```
Install the dependencies.
```
pip install -r requirements.txt
```

Add the configuration for your client:

{
    "mcpServers": {
        "pexels": {
            "command": "python3",
            "args": ["-m", "pexels_mcp_server"],
            "env": {
                "PEXELS_API_KEY": "<Your Pexels API key>"
            }
        }
    }
}

Using `pip` globally

Ensure pip or pip3 is available on your system.

pip install pexels-mcp-server
# or
pip3 install pexels-mcp-server

MCP client code configuration or Claude settings, add pexels mcp server:

{
    "mcpServers": {
        "pexels": {
            "command": "python3",
            "args": ["pexels-mcp-server"],
            "env": {
                "PEXELS_API_KEY": "<Your Pexels API key>"
            }
        }
    }
}

Debugging

You can use the MCP inspector to debug the server. For uvx installations:

npx @modelcontextprotocol/inspector uvx pexels-mcp-server

Or if you've installed the package in a specific directory or are developing on it:

git clone https://github.com/garylab/pexels-mcp-server.git
cd pexels-mcp-server
npx @modelcontextprotocol/inspector uv run pexels-mcp-server -e PEXELS_API_KEY=<the key>

License

pexels-mcp-server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

Available Tools

8 tools

collections_featuredC

List featured collections

ParametersJSON Schema

Name	Required	Description	Default
`per_page`	No	Results per page (string, 1-80)	15
`page`	No	Page number (string, minimum 1)	1

TDQS

C2.2/5.0

Behavior1/5

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

No annotations exist, so the description carries full burden. It discloses no behavioral traits such as read-only nature, side effects, or safety. The description is completely opaque about what 'list' entails (e.g., rate limits, auth, or data structure).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only 4 words, which is concise but under-specified. It restates the tool name without adding value, making it tautological rather than helpfully succinct.

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 2 parameters, no output schema, and no annotations, the description fails to explain what 'featured collections' are, pagination behavior beyond schema, or how results are structured. It is minimally 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?

The schema covers 100% of parameters with descriptions, so baseline is 3. The tool description adds no additional 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.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List featured collections' is clear in verb and resource, but it does not differentiate from siblings like 'collections_media'. The term 'featured' is implied by the name, so the description adds minimal new meaning.

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 such as 'collections_media' or 'photos_curated'. There is no mention of context, prerequisites, or exclusion criteria.

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

collections_mediaC

List collection media

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Collection ID
`type`	No	photos \| videos \| all
`per_page`	No	Results per page (string, 1-80)	15
`page`	No	Page number (string, minimum 1)	1

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only says 'List collection media'. It fails to disclose pagination behavior, response format, error handling, or any side effects. For a listing tool with parameters for page/per_page, 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.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

At three words, the description is too sparse. It lacks necessary detail to be helpful, crossing from concise to under-specified. Every word should add value; here it barely states the obvious.

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 4 parameters, no output schema, and no annotations, the description omits crucial context like default sorting, return structure, and error behavior. It is incomplete for effective tool selection and invocation.

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%; the schema already explains id, type, per_page, and page. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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 'List collection media' clearly states the action (list) and resource (collection media). It distinguishes from siblings like photo_get (single photo) and videos_popular (videos list) by focusing on collection-scoped media, though it does not explicitly differentiate.

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 siblings such as collections_featured, photo_get, or videos_search. There are no conditions, exclusions, or context hints for selection.

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

photo_getB

Get a photo by id

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Photo ID (string, positive integer)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or behavior on missing IDs.

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 with no unnecessary words. It is appropriately brief for a simple get operation.

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 high schema coverage and a single parameter, the description lacks information about return values or error handling. With no output schema, the agent is left guessing what the response contains.

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 value beyond the schema for the 'id' parameter. It redundantly states 'by id' but does not enrich semantics.

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 'Get a photo by id' uses a specific verb and resource, clearly distinguishing it from sibling tools like photos_curated or photos_search which list or search photos.

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. It does not mention prerequisites or typical use cases.

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

photos_curatedC

List curated photos

ParametersJSON Schema

Name	Required	Description	Default
`per_page`	No	Results per page (string, 1-80)	15
`page`	No	Page number (string, minimum 1)	1

TDQS

C2.9/5.0

Behavior1/5

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

No annotations provided, and the description adds no behavioral context such as ordering, caching, rate limits, or what 'curated' entails. It only says 'list', which is minimal.

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, using a clear phrase. However, it is a fragment rather than a complete sentence, and the structure lacks any additional sections or context.

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 simplicity of the tool (two optional parameters, no output schema), the description is adequate but could be more complete by explaining what 'curated' means or if there are any default behaviors.

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 both parameters have descriptions in the schema. The description does not add extra meaning beyond what the schema already provides, so 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?

Description clearly states 'List curated photos' with a specific verb and resource. It distinguishes from sibling tools like photos_search (search) and photo_get (single photo) by specifying 'curated'.

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 vs alternatives like photos_search or collections_featured. The description only states what it does, not the context or exclusions.

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

photos_searchC

Search photos on Pexels

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query
`per_page`	No	Results per page (string, 1-80)	15
`page`	No	Page number (string, minimum 1)	1
`orientation`	No	landscape \| portrait \| square
`size`	No	large \| medium \| small
`color`	No	Color name or hex (e.g. #ff0000)
`locale`	No	Locale, e.g. en-US

TDQS

C2.9/5.0

Behavior2/5

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

The description is too minimal to disclose behavioral traits. With no annotations, it fails to indicate pagination, rate limits, or whether the operation is read-only. The word 'Search' implies read-only but 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence. It is front-loaded and efficient, though it could benefit from added context without sacrificing brevity.

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 7 parameters and no annotations or output schema, the description is incomplete. It should clarify return format, filtering behavior, and when to use this over sibling tools.

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?

All 7 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches photos on Pexels, distinguishing it from siblings that target collections, single photos, or videos. However, it does not specify scope or uniqueness relative to 'photos_curated'.

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 'photos_curated' or 'video_search'. The description lacks any contextual hints for selection.

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

video_getB

Get a video by id

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Video ID (string, positive integer)

TDQS

B3.1/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 does not disclose any behavioral traits such as read-only nature, authorization needs, or side effects. The minimal description fails to add value beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short and to the point, but it lacks any structured information such as return value hints or usage examples. It is concise but minimally helpful.

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 tool's simplicity (one parameter, no output schema, no annotations), the description is functionally complete but lacks behavioral context. It does not explain the return format or any constraints, which would improve 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 schema description coverage is 100% (the 'id' parameter has a description). The tool description does not add any additional meaning beyond what the schema already provides, so a 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 'Get a video by id' uses a specific verb and resource, clearly indicating the tool retrieves a single video. It distinguishes itself from sibling tools like 'videos_search' and 'videos_popular' which are for listing or searching.

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. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.

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

videos_popularC

List popular videos

ParametersJSON Schema

Name	Required	Description	Default
`per_page`	No	Results per page (string, 1-80)	15
`page`	No	Page number (string, minimum 1)	1
`min_width`	No	Minimum video width (string, positive integer)
`min_height`	No	Minimum video height (string, positive integer)
`min_duration`	No	Minimum duration in seconds (string, positive integer)
`max_duration`	No	Maximum duration in seconds (string, positive integer)

TDQS

C2.3/5.0

Behavior1/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states 'List popular videos' without mentioning pagination, ordering, scope, or what constitutes 'popular'. This is a significant omission for a listing endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief (4 words) and front-loaded, but it is too sparse. While concise, it fails to provide necessary detail, making it under-specified rather than efficiently informative.

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 6 optional parameters and no output schema, the description should clarify return type, pagination behavior, and the definition of 'popular'. It lacks this context, leaving the agent with incomplete information to use the tool effectively.

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 baseline is 3. The description adds no additional context about parameters; it does not explain how parameters affect results or any special behavior (e.g., filtering by width/height). Thus, it meets the baseline but does not exceed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description provides a verb and resource ('List popular videos'), but lacks specificity on what 'popular' means and how it differs from sibling tools like videos_search. It is clear enough for a basic understanding but insufficient for precise tool selection.

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 videos_search or photo_get. The description does not mention context, prerequisites, or exclusions, leaving the agent without decision support.

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

videos_searchC

Search videos on Pexels

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query
`per_page`	No	Results per page (string, 1-80)	15
`page`	No	Page number (string, minimum 1)	1
`orientation`	No	landscape \| portrait \| square
`size`	No	large \| medium \| small
`locale`	No	Locale, e.g. en-US

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, and the description gives no behavioral details such as search scope, sorting, or result structure. For example, it does not mention that results are paginated or that the API may impose rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, but it is not front-loaded with key information that aids tool selection. It is minimally adequate but lacks structure to quickly convey purpose.

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 6 parameters and no output schema, the description fails to explain return values or pagination behavior. For a search tool, it should mention that results include video objects and metadata.

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 no additional meaning beyond what the schema already provides (e.g., parameter descriptions).

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 'Search videos on Pexels' clearly states the action (search) and resource (videos on Pexels). However, it does not differentiate from sibling tools like 'videos_popular' or 'video_get', lacking specificity.

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 'videos_popular' or 'photo_search'. The description provides no context for selection.

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.

8 tool updatesv0.1.0Jun 11, 2026
- First observedcollections_featured
- First observedcollections_media
- First observedphoto_get
- First observedphotos_curated
- First observedphotos_search
- First observedvideo_get
- First observedvideos_popular
- First observedvideos_search

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct resource or action: collections, photos, and videos are clearly separated with no overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent resource_action pattern (e.g., collections_featured, photos_search) using snake_case and clear verbs.

Tool Count5/5

Eight tools cover the essential operations for a media API, providing a balanced set without unnecessary clutter or missing core features.

Completeness4/5

The surface includes search, get by ID, and curated/popular lists for photos and videos, and featured collections with media listing. Minor gaps like collection search or photo upload are acceptable given the read-only nature.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Studex MCP ServerOAuth
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1
l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237

Related MCP Servers

Pixabay MCP Server
Image & Video Processing Search
zym9863
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables searching for images on Pixabay with query parameters and returns formatted results with image URLs and metadata.
Updated 6 months ago (2026-03-22 04:02 UTC)
2
45
8
MIT
Lorem Ipsum MCP Server
ssv445
F
license
B
quality
D
maintenance
A Model Context Protocol server that enables image generation and retrieval from picsum.photos with customizable parameters like dimensions, filters, and output formats.
Updated a year ago (2025-07-14 02:56 UTC)
1
-
pexels-mcp-pro
Search Image & Video Processing
fkilter
A
license
A
quality
C
maintenance
An MCP server for the Pexels API that provides inline visual previews, video storyboards, and batch operations for efficient stock media selection in Claude and other MCP clients.
Updated a month ago (2026-07-28 11:43 UTC)
13
MIT
mcp-pexels
Entertainment & Media Search
developer-ishan
A
license
A
quality
C
maintenance
A Model Context Protocol server that exposes Pexels API tools for searching and retrieving free stock photos, videos, and curated collections, enabling AI agents to incorporate royalty-free media directly from chat.
Updated 4 months ago (2026-05-18 20:50 UTC)
2
9
145
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/garylab/pexels-mcp-server'

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

Pexels MCP Server

Available Tools

Usage

Using uv (recommended)

Using pip for a project

Using pip globally

Debugging

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Using `uv` (recommended)

Using `pip` for a project

Using `pip` globally