Skip to main content
Glama
magarcia

MCP Server Giphy

by magarcia

MCP サーバー Giphy

鍛冶屋のバッジ CI npmバージョン npmダウンロード ライセンス: MIT

Giphy API 用の MCP サーバー。AI モデルが Giphy から GIF を検索、取得、利用できるようになります。

特徴

  • コンテンツフィルタリング: 適切なコンテンツを確保するために、評価(G、PG、PG-13、R)で結果をフィルタリングします。

  • 最適化された応答形式: AIモデルの使用に最適化された応答データ

  • 複数の検索方法: クエリベース、ランダム、トレンドのGIF検索をサポート

  • 包括的なメタデータ: 各GIFには、寸法、形式、帰属情報などの完全なメタデータが付属しています。

  • ページネーションのサポート: 効率的な API の使用のために結果のサイズとページネーションを制御します

ツール

  1. search_gifs

    • クエリ文字列を使ってGiphyでGIFを検索する

    • 入力:

      • query (文字列): 検索クエリの用語またはフレーズ

      • limit (オプションの数値): 返されるオブジェクトの最大数 (デフォルト: 10、最大: 50)

      • offset (オプションの数値):結果のオフセット(デフォルト:0)

      • rating (オプションの文字列): コンテンツのレーティング(g、pg、pg-13、r)

      • lang (オプションの文字列): 言語コード (デフォルト: en)

    • 戻り値: メタデータを含むGIFオブジェクトの配列

  2. get_random_gif

    • GiphyからランダムなGIFを取得し、オプションでタグでフィルタリングします

    • 入力:

      • tag (オプションの文字列):ランダムな結果を制限するためのタグ

      • rating (オプションの文字列): コンテンツのレーティング(g、pg、pg-13、r)

    • 戻り値: メタデータを含むランダムGIFオブジェクト

  3. get_trending_gifs

    • Giphyで今話題の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のURL

  • images : さまざまな画像形式を含むオブジェクト。それぞれ次のようになります:

    • url : 画像ファイルへの直接URL

    • width : 画像の幅

    • height : 画像の高さ

  • 利用可能な場合の追加メタデータ

設定

Smithery経由でインストール

Smithery経由で Claude Desktop 用の mcp-server-giphy を自動的にインストールするには:

npx -y @smithery/cli install mcp-server-giphy --client claude

Giphy APIキー

Giphy APIキーを作成します:

  • Giphy開発者アカウントに登録する

  • APIキーを取得するためのアプリを作成する

  • ニーズに応じて無料プランまたは有料プランからお選びください

環境設定

API キーを使用して.envファイルを作成します。

GIPHY_API_KEY=your_api_key_here

Claude 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 tools
get_random_gifA

Get a random GIF from Giphy, optionally filtered by tag

ParametersJSON Schema
NameRequiredDescriptionDefault
tagNoTag to limit random results (optional)
ratingNoContent rating (g, pg, pg-13, r)

TDQS

A3.5/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 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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

search_gifsC

Search for GIFs on Giphy with a query string

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query term or phrase
limitNoMaximum number of objects to return (default: 10, max: 50)
offsetNoResults offset (default: 0)
ratingNoContent rating (g, pg, pg-13, r)
langNoLanguage code (default: en)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 3 tool updates
    • First observedget_random_gif
    • First observedget_trending_gifs
    • First observedsearch_gifs

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    This 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.
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    An 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.
    -
  • -
    license
    Not graded
    quality
    Not graded
    maintenance
    An 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.
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    An 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.
    -