mcp-server-pexels
mcp-server-pexels
Ein MCP-Server für die Suche nach Stockfotos und -videos von Pexels. Optimiert für LLMs.
Pexels bietet kostenlose Stockfotos und -videos.
Funktionen
Fotosuche — Suche nach Fotos mit Filtern (Suchbegriff, Ausrichtung, Größe, Farbe, Gebietsschema)
Videosuche — Suche nach Videos, wählt automatisch das HD-.mp4-Video aus, das 1920x1080 am nächsten kommt
Details abrufen — Vollständige Metadaten für ein Foto/Video per ID abrufen
Intelligentes Caching — 10 Min. TTL für Suchen, 60 Min. für ID-Abfragen
Fehlerbehandlung — Sanfte Fehlerbehandlung mit hilfreichen Meldungen (gemäß MCP-Best-Practices)
Namensnennung — Obligatorische Fotografen-Credits in jedem Ergebnis
Related MCP server: Pexels MCP Server
Voraussetzungen
Node.js v20+
Pexels API-Schlüssel (kostenlos unter pexels.com/api)
Schnellstart (2 Minuten)
1. API-Schlüssel erhalten
Registrieren Sie sich unter pexels.com/api — kostenlos, keine Kreditkarte erforderlich.
2. Server erstellen
npm install && npm run build3. Zu Claude Desktop hinzufügen
Öffnen Sie ~/Library/Application Support/Claude/claude_desktop_config.json (Mac) oder %APPDATA%\Claude\claude_desktop_config.json (Windows) und fügen Sie Folgendes hinzu:
{
"mcpServers": {
"pexels": {
"command": "node",
"args": ["/absolute/path/to/mcp-server-pexels/build/index.js"],
"env": {
"PEXELS_API_KEY": "YOUR_PEXELS_API_KEY"
}
}
}
}Windows-Hinweis: Verwenden Sie den vollständigen Pfad zu
node.exeoder fügen Sie Node zum PATH hinzu. Schrägstriche in Pfaden funktionieren unter Windows.
4. Claude Desktop neu starten
Der Server ist nun als pexels_search_photos, pexels_search_videos und pexels_get_details verfügbar.
Konfiguration
Fügen Sie dies zu Ihrer .mcp.json oder claude_desktop_config.json hinzu:
{
"mcpServers": {
"pexels": {
"command": "node",
"args": ["/absolute/path/to/build/index.js"],
"env": {
"PEXELS_API_KEY": "YOUR_API_KEY"
}
}
}
}Umgebung
Setzen Sie PEXELS_API_KEY in Ihrer Umgebung. Erstellen Sie für die lokale Entwicklung eine .env-Datei:
PEXELS_API_KEY=your_pexels_api_keyEntwicklung
npm run dev # watch mode
npm run inspector # MCP Inspector
npm test # run testsTools
Tool | Beschreibung |
| Nach Fotos per Suchbegriff suchen |
| Nach Videos suchen |
| Details nach ID und Typ abrufen |
Architektur
src/index.ts— Einstiegspunkt, MCP-Server-Setupsrc/tools/— Tool-Implementierungensrc/shared/— Cache, API-Client, Fehler, Typen, Video-Selektorsrc/utils/— Zod-Validierungsschemata
Technische Entscheidungen
Entscheidung | Begründung |
Cache-First-Architektur | Die Pexels-API erlaubt 200 Anfragen/Stunde. Caching (10 Min. TTL für Suchen, 60 Min. für ID-Abfragen) schont das Kontingent, reduziert die Latenz bei einem Cache-Treffer auf <5 ms und demonstriert das Bewusstsein für API-Kosten — entscheidend für produktive KI-Systeme, bei denen Agenten häufig denselben Kontext erneut anfordern. |
Fail-Fast beim Aufruf | MCP-Server werden als Kindprozesse gestartet — der Start ist nicht der richtige Zeitpunkt für Fehler. Der Server warnt beim Start, schlägt aber beim ersten Tool-Aufruf mit einer strukturierten |
Zod-Validierungsschemata | Das MCP v2 SDK erfordert |
resource_link für Medien | Remote-Bilder und -Videos werden als MCP |
Reine Videoauswahl | Die Logik zur Videoauswahl ist in |
Hardcodierte Namensnennung | Erforderlich durch die Nutzungsbedingungen von Pexels. In jede Textantwort eingebettet. |
Kompatibilität
Getestet mit @modelcontextprotocol/sdk v1.29+ via StdioClientTransport. Die Integrationstest-Suite startet den erstellten Server und validiert jeden Tool-Aufruf gegen das CallToolResultSchema und ContentBlockSchema des SDKs.
Ein strukturierter JSON-Block wird als letztes Inhaltselement an jede erfolgreiche Antwort angehängt und enthält typisierte Daten (ID, Art, Erstellername, Abmessungen, URLs). Nachgelagerte Clients und Agenten-Frameworks können diesen Block direkt parsen, anstatt den Markdown-Text per Regex zu analysieren.
Zukünftige Verbesserungen
Tool-Ausführungs-Telemetrie — Hinzufügen von strukturiertem Logging für Cache-Treffer/-Fehlschläge, Abfrageausführungszeit und Fehlerraten. Dies unterstützt die Fehlerbehebung bei KI-Agenten in der Produktion und demonstriert Best Practices für die Beobachtbarkeit.
Metriken-Endpunkt — Bereitstellung von Zählern (bediente Anfragen, Cache-Trefferquote, verbleibendes API-Kontingent) für das Monitoring.
Benutzerdefinierte TTL-Konfiguration — Ermöglicht Benutzern die Anpassung der Cache-TTL über Umgebungsvariablen.
Community-Beiträge
sind willkommen! 🌟
Lizenz
Inoffizielles Community-Projekt. Nicht mit Pexels verbunden.
Available Tools
3 toolspexels_get_detailsGet Pexels DetailsARead-onlyIdempotent
Get detailed information about a specific photo or video by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| type | Yes | ||
| force_refresh | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds that it returns 'detailed information' but does not disclose any additional behavioral traits like rate limits or required permissions.
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 a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose.
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?
For a simple tool with three parameters and no output schema, the description is minimally adequate. It fails to hint at the output format or behavior of the optional 'force_refresh' parameter, leaving some gaps.
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?
With 0% schema description coverage, the description should compensate. It only mentions 'by ID', leaving parameters like 'type' and 'force_refresh' unexplained. While the enum for type provides some guidance, the description adds minimal value beyond the schema.
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?
Description clearly states the verb 'Get', resource 'detailed information about a specific photo or video', and method 'by ID'. It effectively distinguishes from sibling search tools (pexels_search_photos, pexels_search_videos) which query by keywords.
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 implies usage when a specific ID is known, contrasting with search tools. However, it does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pexels_search_photosSearch Pexels PhotosARead-onlyIdempotent
Search for stock photos by query with optional filters for orientation, size, color, and locale. Returns 3-5 results with mandatory photographer attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| orientation | No | ||
| size | No | ||
| color | No | ||
| locale | No | ||
| per_page | No | ||
| force_refresh | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| kind | Yes | |
| creatorName | Yes | |
| creatorUrl | Yes | |
| pageUrl | Yes | |
| previewUrl | Yes | |
| mediaUrl | Yes | |
| mediaMimeType | Yes | |
| dimensions | Yes | |
| avgColor | Yes | |
| alt | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds valuable behavioral details: returns 3-5 results and requires photographer attribution, which goes beyond annotations.
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 two sentences, extremely concise, with no filler. Every word adds value.
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 presence of an output schema and annotations, the description covers core functionality well. It lacks mention of per_page and force_refresh, but is otherwise sufficient 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 mentions four optional filters (orientation, size, color, locale), adding semantic context that they are filters. However, it omits per_page and force_refresh, and schema coverage is 0%. The added value is marginal.
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 'Search for stock photos by query with optional filters', specifying verb and resource. It distinguishes from siblings (pexels_get_details for individual photos, pexels_search_videos for videos) by focusing on photo search.
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?
While the purpose is clear, the description does not provide explicit guidance on when to use this tool versus its siblings or alternatives. Usage is implied but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pexels_search_videosSearch Pexels VideosARead-onlyIdempotent
Search for stock videos by query with optional filters. Returns HD-quality .mp4 links with mandatory attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| orientation | No | ||
| size | No | ||
| locale | No | ||
| per_page | No | ||
| force_refresh | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| kind | Yes | |
| creatorName | Yes | |
| creatorUrl | Yes | |
| pageUrl | Yes | |
| previewUrl | Yes | |
| mediaUrl | Yes | |
| mediaMimeType | Yes | |
| dimensions | Yes | |
| durationSeconds | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, non-destructive, idempotent behavior. The description adds value by disclosing that results are HD-quality .mp4 links with mandatory attribution, which are not implied by annotations.
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 a single sentence that front-loads the action and key details. Every word earns its place with no fluff.
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?
The output schema exists, covering return values. The description adds helpful context on output format and attribution. Missing aspects like pagination and enum specifics are minor given overall clarity.
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?
Schema description coverage is 0%, but the description provides no individual parameter explanations. It only mentions 'optional filters' generically, failing to compensate for the missing schema descriptions of the 6 parameters.
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 searches for stock videos by query with optional filters. It mentions HD-quality .mp4 links and mandatory attribution, which distinguishes it from sibling tools like pexels_search_photos (photos) and pexels_get_details (details).
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 implies usage for video searches via 'stock videos' and optional filters, but does not explicitly state when to use this tool over siblings. However, the tool name and context signals make the distinction clear.
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.
2 tool updates
- Changed
pexels_search_photos1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "alt": { + "type": "string" + }, + "avgColor": { + "type": "string" + }, + "creatorName": { + "type": "string" + }, + "creatorUrl": { + "type": "string" + }, + "dimensions": { + "additionalProperties": false, + "properties": { + "height": { + "type": "number" + }, + "width": { + "type": "number" + } + }, + "required": [ + "width", + "height" + ], + "type": "object" + }, + "id": { + "type": "number" + }, + "kind": { + "const": "photo", + "type": "string" + }, + "mediaMimeType": { + "const": "image/jpeg", + "type": "string" + }, + "mediaUrl": { + "type": "string" + }, + "pageUrl": { + "type": "string" + }, + "previewUrl": { + "type": "string" + } + }, + "required": [ + "id", + "kind", + "creatorName", + "creatorUrl", + "pageUrl", + "previewUrl", + "mediaUrl", + "mediaMimeType", + "dimensions", + "avgColor", + "alt" + ], + "type": "object" +}
- Changed
pexels_search_videos1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "creatorName": { + "type": "string" + }, + "creatorUrl": { + "type": "string" + }, + "dimensions": { + "additionalProperties": false, + "properties": { + "height": { + "type": "number" + }, + "width": { + "type": "number" + } + }, + "required": [ + "width", + "height" + ], + "type": "object" + }, + "durationSeconds": { + "type": "number" + }, + "id": { + "type": "number" + }, + "kind": { + "const": "video", + "type": "string" + }, + "mediaMimeType": { + "type": "string" + }, + "mediaUrl": { + "type": "string" + }, + "pageUrl": { + "type": "string" + }, + "previewUrl": { + "type": "string" + } + }, + "required": [ + "id", + "kind", + "creatorName", + "creatorUrl", + "pageUrl", + "previewUrl", + "mediaUrl", + "mediaMimeType", + "dimensions", + "durationSeconds" + ], + "type": "object" +}
3 tool updates
v1.0.0- First observed
pexels_get_details - First observed
pexels_search_photos - First observed
pexels_search_videos
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: searching photos, searching videos, and getting details by ID. No overlap or ambiguity.
All tools follow a consistent 'pexels_verb_noun' pattern using snake_case, making it predictable for an agent to infer functionality.
Three tools is minimal but appropriate for a focused image/video search service. It covers the core workflow without unnecessary bloat.
The set covers search and retrieval of photos and videos, but lacks features like curated collections or trending content, which are minor omissions.
Maintenance
Related MCP Connectors
Search photos/videos; manage collections, people and duplicates. Requires paid OwAI Cloud Access.
Find free-to-use stock photos by words, by image or by similarity; every result names its licence.
Google, Bing, DuckDuckGo and Google Maps search results, free without an API key.
Image Search: Fast and Simple Image Search API. You can get 100+ search results in one query!.
Related MCP Servers
- AlicenseAqualityCmaintenanceA Model Context Protocol server that extracts images from URLs or base64 data and converts them into a format suitable for LLM analysis, allowing AI models to process and understand visual content.3952 npm21MIT
- AlicenseNot gradedqualityDmaintenanceEnables searching and retrieving high-quality stock photos from Pexels with advanced filtering options including orientation, size, color, and localization support.29 npmISC
- AlicenseCqualityFmaintenanceEnables AI models to search and retrieve photos, videos, and collections from Pexels via the Pexels API.1129 npm9ISC
- FlicenseNot gradedqualityDmaintenanceEnables searching and displaying high-quality, royalty-free photos from Pexels directly in ChatGPT conversations via an interactive gallery widget.2-