MCP Server Giphy
MCP 서버 Giphy
Giphy API를 위한 MCP 서버로, AI 모델이 Giphy에서 GIF를 검색, 추출, 활용할 수 있도록 지원합니다.
특징
콘텐츠 필터링 : 적절한 콘텐츠를 보장하기 위해 등급(G, PG, PG-13, R)별로 결과를 필터링합니다.
최적화된 응답 형식 : AI 모델 소비에 최적화된 응답 데이터
다양한 검색 방법 : 쿼리 기반, 무작위 및 추세 GIF 검색 지원
포괄적인 메타데이터 : 각 GIF에는 크기, 형식 및 속성을 포함한 전체 메타데이터가 제공됩니다.
페이지 매김 지원 : 효율적인 API 사용을 위해 결과 크기 및 페이지 매김 제어
도구
search_gifs쿼리 문자열을 사용하여 Giphy에서 GIF 검색
입력:
query(문자열): 검색어 또는 구문limit(선택적 숫자): 반환할 최대 객체 수(기본값: 10, 최대값: 50)offset(선택적 숫자): 결과 오프셋(기본값: 0)rating(선택 문자열): 콘텐츠 등급(g, pg, pg-13, r)lang(선택적 문자열): 언어 코드(기본값: en)
반환: 메타데이터가 포함된 GIF 객체 배열
get_random_gifGiphy에서 무작위 GIF를 가져오세요. 선택적으로 태그로 필터링할 수 있습니다.
입력:
tag(선택적 문자열): 무작위 결과를 제한하는 태그rating(선택 문자열): 콘텐츠 등급(g, pg, pg-13, r)
반환: 메타데이터가 포함된 무작위 GIF 객체
get_trending_gifsGiphy에서 현재 인기 있는 GIF를 받아보세요
입력:
limit(선택적 숫자): 반환할 최대 객체 수(기본값: 10, 최대값: 50)offset(선택적 숫자): 결과 오프셋(기본값: 0)rating(선택 문자열): 콘텐츠 등급(g, pg, pg-13, r)
반환: 메타데이터가 포함된 인기 GIF 객체 배열
Related MCP server: Giphy MCP Server
응답 형식
응답의 각 GIF에는 다음이 포함됩니다.
id: 고유한 Giphy 식별자title: GIF 제목url: Giphy 웹사이트의 GIF URLimages: 다양한 이미지 형식을 포함하는 객체로, 각각 다음이 포함됩니다.url: 이미지 파일에 대한 직접 URLwidth: 이미지 너비height: 이미지 높이
추가 메타데이터가 있는 경우
설정
Smithery를 통해 설치
Smithery를 통해 Claude Desktop용 mcp-server-giphy를 자동으로 설치하려면:
지엑스피1
Giphy API 키
Giphy 개발자 계정에 가입하세요
API 키를 얻기 위한 앱 만들기
귀하의 요구 사항에 따라 무료 계층 또는 유료 옵션 중에서 선택하세요
환경 구성
API 키로 .env 파일을 만듭니다.
GIPHY_API_KEY=your_api_key_hereClaude Desktop과 함께 사용
Claude Desktop과 함께 사용하려면 claude_desktop_config.json 에 다음을 추가하세요.
{
"mcpServers": {
"giphy": {
"command": "npx",
"args": ["-y", "mcp-server-giphy"],
"env": {
"GIPHY_API_KEY": "<YOUR_API_KEY>"
}
}
}
}개발
# Install dependencies
npm install
# Build the project
npm run build
# Start the server
npm start
# Run in development mode with hot reloading
npm run dev
# Run tests
npm test
# Use with MCP Inspector
npm run inspector특허
이 MCP 서버는 MIT 라이선스에 따라 라이선스가 부여됩니다. 즉, MIT 라이선스의 조건에 따라 소프트웨어를 자유롭게 사용, 수정 및 배포할 수 있습니다. 자세한 내용은 프로젝트 저장소의 LICENSE 파일을 참조하세요.
Available Tools
3 toolsget_random_gifA
Get a random GIF from Giphy, optionally filtered by tag
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Tag to limit random results (optional) | |
| rating | No | Content rating (g, pg, pg-13, r) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool fetches from Giphy but doesn't disclose behavioral traits like rate limits, authentication needs, response format, or error handling. For an external API tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that front-loads the core purpose ('Get a random GIF from Giphy') and adds optional detail ('optionally filtered by tag') without waste. Every word earns its place, making it appropriately sized and well-structured.
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 moderate complexity (external API call with parameters) and no annotations or output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, response format, or error handling, leaving gaps that could hinder effective use by an 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?
Schema description coverage is 100%, so the schema already documents both parameters ('tag' and 'rating') with descriptions and enum values. The description adds minimal value by mentioning optional tag filtering, but doesn't provide additional syntax or context beyond what the schema provides, meeting the baseline for high coverage.
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 specific action ('Get a random GIF') and resource ('from Giphy'), with optional filtering by tag. It distinguishes from siblings by specifying 'random' (vs. 'trending' or 'search'), making the purpose explicit and differentiated.
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 random GIF retrieval, but provides no explicit guidance on when to use this tool versus alternatives like 'get_trending_gifs' or 'search_gifs'. It mentions optional tag filtering, which hints at context, but lacks clear when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trending_gifsC
Get currently trending GIFs on Giphy
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of objects to return (default: 10, max: 50) | |
| offset | No | Results offset (default: 0) | |
| rating | No | Content rating (g, pg, pg-13, r) |
TDQS
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 states what the tool does but doesn't add any behavioral context beyond that—such as rate limits, authentication requirements, or what the output looks like (e.g., format, pagination details). This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain behavioral aspects like rate limits or output format, which are crucial for proper tool invocation. For a tool with three parameters and no structured output information, more context is needed to be fully helpful.
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 input schema has 100% description coverage, with clear documentation for all three parameters (limit, offset, rating). The description doesn't add any parameter semantics beyond what the schema provides, so it meets the baseline score of 3 where the schema does the heavy lifting.
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 verb ('Get') and resource ('currently trending GIFs on Giphy'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_random_gif' or 'search_gifs', which would require mentioning it's specifically for trending content rather than random or search-based retrieval.
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 like 'get_random_gif' or 'search_gifs'. It lacks any context about scenarios where trending GIFs are preferred over random or searched ones, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_gifsC
Search for GIFs on Giphy with a query string
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query term or phrase | |
| limit | No | Maximum number of objects to return (default: 10, max: 50) | |
| offset | No | Results offset (default: 0) | |
| rating | No | Content rating (g, pg, pg-13, r) | |
| lang | No | Language code (default: en) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('Search for GIFs') but fails to disclose critical traits like rate limits, authentication needs, error handling, or response format. This leaves significant gaps for an agent to understand operational behavior.
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, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity of a search tool with 5 parameters and no output schema or annotations, the description is incomplete. It lacks details on behavioral aspects, usage context, and output expectations, leaving the agent with insufficient information 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what the schema provides, such as usage examples or constraints not in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Search for GIFs') and resource ('on Giphy'), with the specific mechanism ('with a query string'). It distinguishes from siblings like 'get_random_gif' and 'get_trending_gifs' by specifying search functionality, though it could be more explicit about the distinction.
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 like 'get_random_gif' or 'get_trending_gifs'. It lacks context such as use cases for search versus random/trending GIFs, making it unclear when this is the appropriate choice.
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.
3 tool updates
- First observed
get_random_gif - First observed
get_trending_gifs - First observed
search_gifs
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: get_random_gif retrieves a single random GIF, get_trending_gifs fetches trending content, and search_gifs performs query-based searches. There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent verb_noun pattern with 'get' or 'search' verbs and descriptive nouns (random_gif, trending_gifs, gifs). The naming is uniform and predictable across the set.
With 3 tools, the server is well-scoped for its purpose of accessing Giphy content. Each tool serves a distinct and essential function (random, trending, search), and there are no extraneous or missing tools for this domain.
The tool surface covers the core workflows for a Giphy API: retrieving random GIFs, accessing trending content, and searching by query. This provides complete coverage for typical use cases without obvious gaps or dead ends.
Maintenance
Related MCP Connectors
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Discover, compare, route, and execute machine-accessible capabilities for AI agents.
Travel tools for AI agents: plan and edit real trips, search stays and tours, import travel videos.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceThis is an auto-generated Multi-Agent Conversation Protocol server that enables interaction with the Giphy API, allowing users to access and use Giphy's GIF services through natural language commands.-
- FlicenseNot gradedqualityDmaintenanceAn MCP (Multi-Agent Conversation Protocol) Server that enables interaction with the Giphy API, allowing agents to search, retrieve, and manage GIF animations through natural language commands.-
- -licenseNot gradedqualityNot gradedmaintenanceAn MCP (Multi-Agent Conversation Protocol) Server that enables interaction with the Giphy API, allowing users to search, retrieve, and manipulate GIF content through natural language commands.-
- FlicenseNot gradedqualityDmaintenanceAn auto-generated Model Context Protocol Server that enables interaction with Giphy's API, allowing users to access and manipulate GIF content through natural language requests.-